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

From: "Goldberg, Adam" <[email-masked]>
Date: Sun, 6 Feb 2005 21:45:46 -0800

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: [email-masked]; 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: [email-masked] [mailto:[email-masked]]
> On
> > > Behalf Of Gorry Fairhurst
> > > Sent: Friday, February 04, 2005 6:56 AM
> > > To: [email-masked]; Bernhard Collini-Nocker
> > > Cc: [email-masked]
> > > 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
> >
> >

---

From: Bernhard Collini-Nocker <[email-masked]>
Date: Mon, 07 Feb 2005 13:48:43 +0100

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 07 Feb 2005 13:54:06 +0000

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

---

From: "Marie-Jose Montpetit" <[email-masked]>
Date: Mon, 7 Feb 2005 15:55:57 -0500

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)
(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
(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

Thanks

Marie-Jose

----- Original Message ----- 
From: "Gorry Fairhurst" <[email-masked]>
To: <[email-masked]>
Cc: "Goldberg, Adam" <[email-masked]>; "Allison, Art"
<[email-masked]>; "Matthew Goldman" <[email-masked]>
Sent: Monday, February 07, 2005 8:54 AM
Subject: Re: Forward from Art Alison: WGLC ULE - Data Broadcast Descripto rs

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 08 Feb 2005 21:36:05 +0000

As the ipdvb WG Chair, let me see if I can frame some questions to the WG as a 
whole (dervied from my understanding of this mail thread)? - This isn't an 
intention to stop discussions (we should address some of the issues raised onm 
the lists in the documents we plan to write), but I am aware that we have a 
document to deliver to the IESG following the WGLC.

----

My three questions are:

A) There was a proposal by a reviewer to change the TITLE of the RFC, to make 
this clearer. The currently suggested new title is:

	"Ultra Lightweight Encapsulation (ULE) for transmission of
  	IP datagrams over an MPEG-2 Transport Stream"

	Instead of the existing title:
  	"Ultra Lightweight Encapsulation (ULE) for transmission of
  	IP datagrams over MPEG-2/DVB networks"

Is the new title acceptable?

----

B) I propose the following text is added to the Introduction, are these 
useful/sufficient?

The MPEG-2 specification [ISO-MPEG2] requires conformant TS
Multiplexes to provide Program Specific Information (PSI) for
each stream in the TS Multiplex. Other MPEG-2 based transmission
standards may also define Service Information (SI). This
information may allow Receivers and Re-multiplexors [draft-ipdvb-arch]
to locate a specific ULE Stream (i.e., the PID value of the TS Logical
Channel that carries a ULE Stream). The conditions under which this
information is required, and the format in which it is to be provided
is beyond the scope of this document. Addressing and mapping issues
for IP over MPEG-2 are described in [draft-ipdvb-ar].

----

C) The terminology "TS Logical Channel" has already been used in another 
document that has passed WGLC. Is it now sufficiently flawed that we MUST be 
replaced in the ULE document, if so why?, If not, I propose we change the 
definition to:

    TS Logical Channel: Transport Stream Logical Channel. In this
    document, this term identifies a channel at the MPEG-2 level [ISO-
    MPEG2]. This 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). The term
    "Stream" is defined in MPEG-2 [ISO-MPEG2]. This describes the content
    carried by a specific TS Logical Channel (see, ULE Stream). Some
    PID values are reserved (by MPEG-2) for specific signalling.
    Other standards (e.g., ATSC, DVB) also reserve specific PID values.

I propose we also add:

     ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE
     encapsulated PDUs. ULE Streams may be identified by definition
     of a ULE stream_type in SI/PSI [ISO_MPEG2].

----

A number of minor corrections have also been made to wording and format, as 
requested by the various reviewers and WG feedback.

The complete set of proposed changes are listed at:
http://www.erg.abdn.ac.uk/ip-dvb/ids/rfcdiff-ule-05f-04.html

Please respond whether you think this revision, is now ready, and we'll try to 
reach a conclusion on whether this document is finally ready to submit.

Gorry Fairhurst
(ipdvb WG Chair)

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 11 Feb 2005 11:58:29 +0000

I'm going to allow a few days for a "final signoff" of the ULE spec, until 
15th Feb 2005 (one week from the email below).

Specifically, I'm looking for the folks who made comments during last call
to check the doc and either indicate "looks OK" or if necessary, submit
replacement text. At this stage, it is important to get "positive" responses 
(as well as raising any issues), so if you have  looked at the changes and 
agree with them, please do send a brief email to the list saying so.

Once submitted, there will be only one last chance to correct this, during the 
final IETF Last Call period, after which this document will be published.

The document is at:
http://www.erg.abdn.ac.uk/ip-dvb/ids/draft-ietf-ipdvb-ule-05f.txt

-- Gorry.

Gorry Fairhurst wrote:
> 
> As the ipdvb WG Chair, let me see if I can frame some questions to the 
> WG as a whole (dervied from my understanding of this mail thread)? - 
> This isn't an intention to stop discussions (we should address some of 
> the issues raised onm the lists in the documents we plan to write), but 
> I am aware that we have a document to deliver to the IESG following the 
> WGLC.
> 
> ----
> 
> My three questions are:
> 
> A) There was a proposal by a reviewer to change the TITLE of the RFC, to 
> make this clearer. The currently suggested new title is:
> 
> document that has passed WGLC. Is it now sufficiently flawed that we 
> MUST be replaced in the ULE document, if so why?, If not, I propose we 
> change the definition to:
> 
> A number of minor corrections have also been made to wording and format, 
> as requested by the various reviewers and WG feedback.
> 
> Please respond whether you think this revision, is now ready, and we'll 
> try to reach a conclusion on whether this document is finally ready to 
> submit.
> 
> Gorry Fairhurst
> (ipdvb WG Chair)
> 
>