RE: ATSC

["Allison, Art" <AAllison@nab.org>]

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:gorry@erg.abdn.ac.uk] 
Sent: Sunday, November 07, 2004 4:42 PM
To: AAllison@nab.org; ipdvb@erg.abdn.ac.uk
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:gorry@erg.abdn.ac.uk]
> Sent: Tuesday, November 02, 2004 6:17 AM
> To: ipdvb@erg.abdn.ac.uk
> Subject: Re: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt
> 
>