[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs

Nothin more to say than:
http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-02.txt


Regards,
Bernhard

Goldberg, Adam wrote:

Below

Adam Goldberg
Director, Television Standards & Policy Development
Sharp Laboratories of America
8605 Westwood Center Drive, Suite 206
Vienna, VA  22182
+1-703-556-4406
+1-703-556-4410 fax
+1-571-276-0305 cell



-----Original Message-----
From: Marie-Jose Montpetit [mailto:mariejose.montpetit@verizon.net]
Sent: Monday, February 07, 2005 3:56 PM
To: ipdvb@erg.abdn.ac.uk
Cc: Goldberg, Adam; Allison, Art; Matthew Goldman
Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto
rs

I think we need to close on some of those issues and move forward.

Here is what I propose which would be inline with the conclusions of the
Architecture Draft:
(1) ULE is encapsulation only - it is not the purpose nor the usage of ULE
to dwell in SI/PSI table issues nor any other protocol; so we leave the
draft to be mostly what it is now (pending small changes proposed by
Gorry)



This becomes a bit self-referential.  The proper definition of the data
stream is to say something like "a stream of stream_type 0xNN", but you
propose not doing this until later.



(2) PSI/SI scanning is part of  the Address Resolution Draft as regard
management of addressing; it will be further discussed there and focus
given
to the issues raised in this thread



Can someone provide a pointer to the "Address Resolution Draft"?



(3) Someone (Adam and/or team) proposes WG work and a draft on ATSC
concerns
on PSI/SI issues and ULE; inclusion of cable TV concerns in addition to
satellite would be welcome and has been one of my goals for the group
(4) we close on ULE and get to discuss the other items further at IETF



Don't misunderstand my concerns (or Art's, I suppose) - they are not "ATSC
concerns" so much as concerns from one overly familiar with MPEG-2 Transport
Streams and their widespread use.




Thanks

Marie-Jose

----- Original Message -----
From: "Gorry Fairhurst" <gorry@erg.abdn.ac.uk>
To: <ipdvb@erg.abdn.ac.uk>
Cc: "Goldberg, Adam" <agoldberg@sharplabs.com>; "Allison, Art"
<aallison@nab.org>; "Matthew Goldman" <mgoldman@3gfp.com>
Sent: Monday, February 07, 2005 8:54 AM
Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto
rs




So....

1. The term "TS Logical Channel" was discussed a lot at the begining of


the


WG. As I recall, the reason for the new term, was that at this time the


WG


could not find a suitably "unbiased" term for the set of TS Packets with


a


common PID value (raw TS, DSMCC, Private Section, PES, etc). One key


objective


was to find a term that did not carry extra semantics, and was


understandable


by the networking community - this is after all intended as a part of


the


RFC-series, and we need to make this accessible to people familiar with


using


IP over Ethernet, MPLS, ATM, Fibre Channel, Firewire, SDH/SONET, etc.
T

we shoudl note that the term "TS Logical Channel term already appears


(and
is


discussed in some detail) in the document draft-ietf-ipvb-arch-xx.txt


and
that


this HAS already complete WGLC.  If it IS WRONG we still have a chance


to
fix


the definition/term, if we have to. Specifically, is there already a
well-accepted term for the set of TS Packets with a common PID value


(raw
TS,


DSMCC, Private Section, PES, etc) that we should use or refer to?


2. I'm not against defining another term "ULE Stream", "SNDU Stream",


etc
if


that helps to describe the set of TS packets with a specific PID used


for
ULE,


especially when talking about PSI.

Bernhard, is there an opportunity of inserting a simple statement as the


final


paragraph of the introduction which says that to use ULE streams within


an


MPEG-2 compliant multiplex may require appropriate PSI entries... I


think
Art


already proposed some specific wording that could be used or modified?


3) Once teh ULE spec is agreed and an RFC number issued, I can also see


great


advantage in assigning a descriptor for this in ATSC. I think the WG


SHOULD


should explore this at the next stage.


Gorry

Bernhard Collini-Nocker wrote:



Hello,

let me try to summarize the two major points being raised and what the
discussion is about:
1. the name/definition of "TS Logical Channel" is not well received


and


the name/definition of a "SNDU stream" is proposed instead
2. it is proposed to consider MPEG-2 conformance in specifying that


ULE


requires a specific stream_type value for the PMT

Personally I have no objection against 1., because it is easy to


change


and improves wording and naming (unless somebody has an even  better
name for it).
For 2. my concern is that mentioning stream_type may require some
additional wording about PSI/SI in general, which is likely out of


scope


of the ULE draft. Even worse, in introducing a "world" besides the
encapsulation/decapsulation of ULE, this may result in further


confusion


about what the MPEG-2/Section layer does in addition to and/or in
comparison to ULE/IP. Actually some difficult question may arise from
this direction, for example whether it is a wishful requirement for


ULE


to support PAT/PMT/NIT/INT/... table parsing?

Any opinions, recommendations or suggestions about this?

Regards,
Bernhard

Goldberg, Adam wrote:



ARGH.  I fat-fingered 'send' before completing the email.  See below.

Adam Goldberg
Director, Television Standards & Policy Development
Sharp Laboratories of America
8605 Westwood Center Drive, Suite 206
Vienna, VA  22182
+1-703-556-4406
+1-703-556-4410 fax
+1-571-276-0305 cell





-----Original Message-----
From: Goldberg, Adam
Sent: Monday, February 07, 2005 12:42 AM
To: 'Bernhard Collini-Nocker'; Goldberg, Adam
Cc: ipdvb@erg.abdn.ac.uk; Allison, Art; Matthew Goldman
Subject: RE: Forward from Art Alison: WGLC ULE - Data Broadcast
Descripto
rs

See below...

Adam Goldberg
Director, Television Standards & Policy Development
Sharp Laboratories of America
8605 Westwood Center Drive, Suite 206
Vienna, VA  22182
+1-703-556-4406
+1-703-556-4410 fax
+1-571-276-0305 cell


Bernhard Collini-Nocker wrote:



Goldberg, Adam wrote:



I apologize for being "late to the party", but:

I do not see a particular need to define new term "TS Logical



Channel",



and



indeed doing so creates risks of ill-specification (such as those


Art



points



out), as well as confusion heaped upon someone familiar with MPEG-


2


Transport (as typically used in entertainment delivery).



Unfortunately the MPEG-2 standards do not provide a reasonable term


for


the purpose of networking. The question is whether other terms, for
example "PID network" or "PID stream" would be better received and
understood?
The term "TS logical channel" tries to verbally visualize that the
encapsulation uses a continouos stream of transport stream packets
using
one specific packet identifier to transport subnetwork data units.
Maybe
the term "TS (virtual) circuit" better names this?



It is perhaps not well defined in 13818-1, but the term of art is
"streams".  Many people use "PID stream" which is a poor combination


of


words.  I'd have no objection to defining a "SNDU Stream" as


something


like "a sequence of MPEG-2 Transport Stream packets identified by a
common
PID value" (or some such).

Perhaps discussing 'virtual circuits' relative to a Transport Stream


is


begging for confusion.  Use of any such words ("TS (virtual)


circuit")


needs careful definition, likely requiring the above SNDU Stream
definition plus an explanation of what it means for multiple SNDU
Streams
to exist in a single Transport Stream.




Furthermore, the definition is quite wrong with respect to ATSC


and



DVB



use



of "specific TS Logical Channels".  To my knowledge, this


internet-



draft



is



the only document anywhere which uses such terms.  It is certainly



true



that



MPEG, DVB and ATSC define //elementary streams// identified by



stream_type



values. I suspect this is what is meant by "TS Logical Channel",


but



it



is



difficult for me to tell.



I am not so sure, whether this analysis is correct. Elementary


streams


are those that are transported as Packetized ES, whereas


"auxillary"


data and signalling is transported as sections. Although a


stream_type


in the program map section is used to reference both PESs and


sections


the term elementary stream is used very vague and we tried to avoid
using it in the same vague manner.



Perhaps I overstepped with "elementary stream".

Consider the 13818-1 definition of "Packetized Elementary Stream":


"A


continuous sequence of PES packets of one elementary stream with one
stream ID may be used to construct a PES Stream." (ISO/IEC
13818-1:2000 p.
xiii)

Stuff carried as payload of Transport Stream packets are merely
'payload'.
What the draft starts to define is a new type of payload stream


(that


is,
a new way to carry data in a transport stream).  The definition is


not


compete.




According to, for example EN301192 v1.3.1, defines Data Piping as:
" The data broadcast service shall insert the data to be broadcast
directly in the payload of MPEG-2 TS packets."
That raises the question, how to call a continouos stream of MPEG-2


TS


packets with a certain PID?

Further the standard details that:
"The data broadcast service may use the


payload_unit_start_indicator


field and the transport_priority field of the MPEG-2 Transport


Stream


packets in a service private way. The use of the adaptation_field


shall


be MPEG-2 compliant."
ULE uses PUSI and does not utilize the AF.

"The delivery of the bits in time through a data pipe is service
private
and is not specified in the present document."
It seems obvious that the use of the term "TS Data Pipe" would lead


to


the wrong conclusion that ULE equals Data Piping. But Data Piping


is


not
detailed at all, whereas ULE tries to be.



I'm not going to argue that DVB's specification is complete.  I will
argue
that ULE isn't complete.




(from the draft)
 TS Logical Channel: Transport Stream Logical Channel. In this
 document, this term identifies a channel at the MPEG-2 level


[ISO-


 MPEG]. It exists at level 2 of the ISO/OSI reference model. All
 packets sent over a TS Logical Channel carry the same PID value
 (this value is unique within a specific TS Multiplex). According


to


 MPEG-2, some TS Logical Channels are reserved for specific
 signalling purposes. Other standards (e.g., ATSC, DVB) also


reserve


 specific TS Logical Channels.

While I'm commenting on this definition, it also seems to me that



"channel



at the MPEG-2 level" is either wrong or also ill-specified.


What's
a


channel?  If you're talking about MPEG-2, it's certainly


conceivable



that



the reader may associate "channel" with "[television] channel" -


which



are



the subject of a large amount of ATSC and DVB systems.



The term channel is indeed problematic in the context of


television,


however, network engineers might have a different understanding


about


what a channel is.
According to ATIS a channel is "1. A connection between initiating


and


terminating nodes of a circuit. 2. A single path provided by a
transmission medium via either (a) physical separation, such as by
multipair cable or (b) electrical separation, such as by frequency-


or


time-division multiplexing. ..."



I understand that 'channel' vis-à-vis networking has a different


meaning


than 'channel' vis-à-vis television.  This was my point actually,


that


those familiar with MPEG transport should not be assumed to be
networking-
types (even when speaking with respect to ULE).




Additionally, it is also wrong or ill-specified to say "According


to



MPEG-2



... TS Logical Channels ...".  There is no such concept defined or



used



within MPEG (unless what you really mean is elementary stream, in



which



case



what do you need this extraneous term for anyhow?).



Again, elementary stream is not exactly what is being meant:
For example EN 300468 v1.5.1 defines:
"component (ELEMENTARY Stream): one or more entities which together
make
up an event, e.g. video, audio, teletext"

and says further:
"The component descriptor identifies the type of component stream


and


may be used to provide a text description of the elementary stream"

where:
"component_type: This 8-bit field specifies the type of the video,
audio
or EBU-data component. The coding of this field is specified in


table



26."



Table 26 then lists all kinds of video, audio, and teletext


formats,


but
unfortunately no networking formats.

At other places this standard is as innovative/creative in naming:
"event: grouping of elementary broadcast data streams with a


defined


start and end time belonging to a common service, e.g. first half


of
a


football match, News Flash, first part of an entertainment show"
What is a "elementary broadcast data streams"? Not by guessing but


by


definition?




In any case, Art is certainly correct that merely identifying a


"TS



Logical



Channel" as a sequence of packets identified with a common PID


value



without



identifying the PSI details is an invitation to multiplexers and
remultiplexers to drop those packets on the floor.



Oh yes, this is the real problem of defining something outside
television standardiszation bodies: one risks that ULE packets are
being
dropped.
We have discussed basically two approaches:
1. define the PSI and get an ID, or tag, or "stream_type" for ULE,
or 2.
define ULE and let somebody else do the PSI work.
We have had some reasons for choice 2.



This is a very easy thing to fix and something which should be done.
Without defining a stream_type for ULE data, it is neither possible


to


construct a transport stream compliant with MPEG-2 nor one that
interoperates with other ULE equipment.

ATSC maintains a 'codepoint registry', and would be happy to


allocate
a


stream_type value for ULE data upon request from IETF.  Furthermore,


the


text to specify usage of the stream_type would be reasonably easy


(and


perhaps ties in to my suggested "SNDU Stream" definition (that is,
define
it as




SNDU Stream: a sequence of MPEG-2 Transport Stream packets identified
by a
common PID value of stream_type <0xnn>.

All that then remains, I think, would be to signal when a Program


carries


SNDU Stream(s), and what it means when there are more than one SNDU
Stream
per program, or more than one Program that carries one or more SNDU
Streams.




If there remains an opportunity to repair what I believe to be


errors



in



the



draft, I'm eager and willing to participate from a MPEG-2



entertainment



(which is to say, legacy use of MPEG-2 Transport) point of view.



Of course the terms in the document should not conflict with


meaning
in


another context. However, ambiguous terms in other documents should


be


avoided as well.




[Apologies for being strident at all, to say nothing of at such an
apparently late stage - if the above is perceived as such]

Regards,
Adam Goldberg
Director, Television Standards & Policy Development
Sharp Laboratories of America
8605 Westwood Center Drive, Suite 206
Vienna, VA  22182
+1-703-556-4406
+1-703-556-4410 fax
+1-571-276-0305 cell


-----Original Message-----
From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-


ipdvb@erg.abdn.ac.uk]



On



Behalf Of Gorry Fairhurst
Sent: Friday, February 04, 2005 6:56 AM
To: ipdvb@erg.abdn.ac.uk; Bernhard Collini-Nocker
Cc: AAllison@nab.org
Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast



Descriptors



1) Done - point 1 was an edit mistake.

2) I think some text on data broadcast descriptors, stream-type,



or/and



PSI



entries would be a valuable addition.

On thinking about this, I wonder if the text about this should go


at



the



end



of the Introduction (1.0) to the whole document, where people can


see



it



clearly and then undesrtand that there may be something else


needed



for



those
networks that rely on PSI for remultiplexing!

- Bernhard & others who understand PSI, can you work with Art to


agree



the



exact wording please?

Gorry Fairhurst
(ipdvb WG Chair)

Gorry Fairhurst wrote:





WG please read and respond to this message.

The following message was received on January 22nd before WGLC,


but



was



dropped because the email source address was not verified by the


list


server.

The exact text of the message follows.

best wishes,

Gorry
(ipdvb WG Chair)

-----



1)




Thanks for considering my previous input...
I note that the new draft has an editorial oversight in that it



contains



two definitions of PSI. I suggest the second should be deleted.



2)




I previously made a comment about the ancillary requirements when



adding



a



TS logical channel to a TS multiplex and asserted there appeared
to be
under
specification. Perhaps it was viewed as out of scope, or perhaps


I



simply



don't recognize the change that resulted.  I can not find what



stream_type



is required to be used for the ULE stream when a "TS Logical


Channel"



is



added to a multiplex.



The problem here is the same as above. Without "applying" for a
"stream_type" for ULE there is no stream_type for ULE. In contrary


why


should one register a stream_type value for ULE earlier than ULE is
standardized?




I suggest at least an informative note be added in Section 6


(after



the



third line which says: "These are transmitted using a single TS



Logical



Channel over a TS Multiplex.") The note should say "PSI entries


to
be


consistent with [ISO-MPEG] when constructing a conformant TS
Multiplex



and



means for Receivers to locate each such TS Logical Channel are
outside



the



scope of this recommendation."



Thanks, this is a very helpful suggestion for potential readers. In
addition the ipdvb-wg works on providing signalling other than


PSI/SI.




Reason:
Just inserting a "TS Logical Channel" without including a
TS_Program_map_section that lists the PID and a stream_type does


not


appear to me to result in a strictly MPEG-2 conformant bit


stream;



and



practically
could result in the PIDs being dropped by a remultiplexer.   If


the



means



for binding the inserted element into a multiplex and subsequent



discovery



is to be covered in another document, a pointer to that document
would



be



more helpful than this warning. It seems at least a warning is


needed



and



preferably a pointer to where this next level of TS construction


is


defined.



From an architectural point of view it is a reasonable assupmption


that


whatever is being sent in a TS multiplex should be referenced.


However,


the reality is that "ghost" PIDs do occur in many services either
accidentially or for well-defined reasons.

What is the penalty for not being strictly MPEG-2


conformant/compliant?




Art Allison
Director, Advanced Engineering
NAB Science & Technology
1771 N St NW, Washington Dc 20036
202 429 5418




Regards,
Bernhard Collini-Nocker