Subject: RE: ATSC

From: "Allison, Art" <[email-masked]>
Date: Mon, 8 Nov 2004 15:07:17 -0500

Gorry
Thanks for the post. I also have been pressed for time. My post was
triggered by the 'fixed PID' discussion. 

The architectural requirements for Scenario A indeed reasonably address the
broadcasting case (and as such did cross the threshold of justifying a last
call comment). But then it seemed those aspects were being ignored by the
discussion of fixed PIDs. While it may be technically feasible to establish
a few logical individual connections from an OTA emission facility and
consumer devices (through use of some other return channel), it is clear
that this does not scale well beyond, say, a few thousand such connections.
This is not a conceptual flaw in the arch doc per se; as parts can be
addressed in different drafts. It seems best to fit the scope of the drafts
to follow to the scenarios they fit.

What does make sense for OTA is multicast, and it appears that perhaps the
needs in the other scenarios and the needs of OTA are enough different that
attempting to have one-to-one  for OTA covered in the same document may
either constrain the other scenarios or inadequately cover OTA. The other
needs seem more pressing as well, perhaps it is wise to separate those and
finish them.

The committee members may find ATSC A/96 - 'Interaction Channel Protocols'
of some interest with respect to the two-way standardization work; though it
may not be directly usable. See http://www.atsc.org/standards/A_96.pdf

Art
-----Original Message-----
From: Gorry Fairhurst [mailto:[email-masked]] 
Sent: Sunday, November 07, 2004 4:42 PM
To: [email-masked]; [email-masked]
Subject: ATSC

Art, 

Sorry for the terse answer, earlier. The authors (and I do expect the WG
too) value the inputs and experience of both the ATSC & DVB communities.

The chief goal of the WG is to develop protocols and documents to define how
the IP protocol suite (both IPv4 and IPv6) is to use these services as a
link within the Internet.  It includes specification of appropriate ways to
bind the end-to-end IP addresses to the L2 network. This also explicitly
includes how arp, neighbor discovery would be used, how to handle multicast
routing, support for Uni-directional links, etc.

There are many scenarios in which MPEG-2 is used, and one of the objectives
of the (arch) document that just went through WGLC was to define specific
scenarios as useful basis for future work. 6 of these were defined. Scenario
A relates to the broadcast TV case (as in figure 4.1 of A/90), which you
referred to. In this case, the text of the Internet Draft seems to follow
the requirements, that you mentioned, i.e.:

Section 3.3 says:
   "In a more complex example, the same TS may be fed to multiple MPEG-2
    multiplexors and these may, in turn, feed other MPEG-2 multiplexors
    (remultiplexing). Remultiplexing may occur in several places (and is
    common in Scenarios A and B of section 3.1)."

And 5.1 says:
   "Elements (ii) and (iii) need to be de-referenced via indexes to the
    Service Information (i.e. the Program Map Table, PMT) when the
    MPEG-2 Transmission Network includes remultiplexors that renumber
    the PID values of the TS Logical Channels that they process. (Note
    that PIDs are not intended to be end-to-end identifiers). However,
    although such use is common in broadcast TV networks, many private
    networks do not need to employ multiplexors that renumber PIDs
   (see section 3.2)."

As far as I can see, the set of ATSC references in the arch document refer
only to push (uni-directional) transmission of IP multicast content.

While IP multicast is in important service for MPEG-2 bearers, the WG scope
is to provide IP in general (unicast, multicast, routing, etc), linking IP
networks using the MPEG-2 link. It would also be useful to point the WG to
any other documents from the ATSC community that relate to two-way IP
services.

Best wishes,

Gorry Fairhurst. 

Allison, Art wrote:
> It should be clear to anyone informed about MPEG2 TS multiplexers that 
> using a fixed PID introduces significant complexity for management of 
> a TS intended for broadcast to consumers. Re-multiplexers drop such 
> PIDs from the stream unless specifically programed for special 
> treatment of the fixed PID (the value of which has to be communicated 
> via 'other' means). IMHO, this makes the entire solution/approach 
> developed by this group generally useless for the transmission path 
> from a broadcaster to the consumer (which also goes through cable system
remultiplexers).
> 
> The address resolution and scoping of 'network' issues have been 
> resolved by the ATSC. The method of delivery of IP traffic that is
documented is proven.
> It is offered in products from multiple vendors and is being used 
> every day (and has been for a few years) in the real world for 
> delivery of IP traffic via over the air broadcast to consumers.
>  
> Inventing another solution for the broadcast OTA link seems to be 
> wasted effort - especially a solution that is fundimentially as flawed 
> as to require a fixed PID.
> 
> Perhaps now is the time to recognize that this IETF work is really 
> optimized for other MPEG-TS-using networks and its claimed scope 
> should be reduced to the other transmission links, where folks 
> determine that the 2.2% overhead the 'fixed PID' approach requires is 
> actually less than one obtains with DSMCC for the traffic they expect to
flow.
> 
> Art Allison
> NAB S&T
> p.s. If someone would like more information see A/92 and applicable 
> parts of A/90 at www.atsc.org. Also note, as it may not be obvious, 
> that the DSMCC-based technology in these standards is seperable from 
> the ATSC announcement technology and then is applicable to any TS.
> 
> -----Original Message-----
> From: Gorry Fairhurst [mailto:[email-masked]]
> Sent: Tuesday, November 02, 2004 6:17 AM
> To: [email-masked]
> Subject: Re: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt
> 
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 09 Nov 2004 20:12:47 -0500

> Gorry

<snip>
> may not be directly usable. See http://www.atsc.org/standards/A_96.pdf
A small correction, the document is at:
 
http://www.atsc.org/standards/a_96.pdf

I'd recommend reading sections  6 & 7 which discuss networking - although
the description is  rather end-host centric, its clear this also anticipates
routing/bridging to a LAN.

Gorry

---

From: Michael A Dolan <[email-masked]>
Date: Thu, 11 Nov 2004 11:10:27 -0800

I observe the work of this group, and regrettably do not have the time to 
actively participate.  I think this has all been said before, and my 
apologies if I am repeating it too much, but maybe a little repeat is OK?

I think the key thing for the group to keep in mind as you review your 
architecture and scope is that there are systems in use today on ATSC and 
DVB MPEG-2 transports that, while simplistic, are not wrong for some 
applications.  And, they are not likely to change, and are in fact 
growing.  These systems followed ISO's recommendation (13818-6 amendment) 
on how to carry network packets.  And, devices today that work with MPEG-2 
are used to encoding and decoding all non-video, non-audio information 
(including network packets and other things) in MPEG-2 sections, not raw 
transport packets.  Devices that handle the multiplexing stages of the 
transport encode and decode processes (which may be different devices) are 
used to operating with these headers without necessarily knowing what's in 
the payload.

For multicast and other inherently large payload packet applications, the 
overhead of the section header is obviously not an issue, and service 
discovery is done by "other means" more compatible with overall service 
discovery on the transport.  Many times, the IP stream is related to only 
one set of components in the multiplex, and service discovery is done at a 
layer higher than the IP stream itself to be sure one decodes the "right" 
IP stream.

That is not to say that an efficient means is not also needed for the 
carriage of small packets (telnet sessions and general IP traffic), and 
design work needed to make an MPEG-2 transport a "real" link route, where 
that is its primary purpose.

Also, be careful how you define the subnet.  An MPEG-2 transport is a 
multiplex, and all components of the multiplex are never decoded 
concurrently, when used for television anyway.  Thus, the subnet is 
something less than the full transport.  A/92 treated this topic.  Also 
note that A/96 is about the return channel operation using more traditional 
transports to connect from the decoder back into the Internet.

Regards,

         Mike