Subject: RE: Proposed Changes to ULE text - Format descriptors for SI sign alling

From: "Allison, Art" <[email-masked]>
Date: Mon, 1 Aug 2005 10:35:39 -0400

See embedded/edit. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, July 31, 2005 4:26 PM
To: [email-masked]
Subject: Re: Proposed Changes to ULE text - Format descriptors for SI
sign alling

Gorry said:
<snip>
The IETF defines (in RFC2119) that SHOULD, means "that there may exist
valid reasons in particular circumstances to ignore a particular item,
but the full implications must be understood and carefully weighed
before choosing a different course".

In this case, it means "implement this" or the implication may be that
the stream is dropped by a TS multiplexor that does not recognise it.

Gorry
<snip>

Art observes:
First, I would not expect lack of an MRD in the  program element loop of
the PMT section to result in dropping the stream with a given PID value.
Lack of an entry (the program element loop) that identifies the PID in
the PMT would be expected to result in the stream being dropped by a
general purpose multiplexer. This situation is sometimes called a
'orphan' PID.  

Second, implementers oft decide not to provide support for optional
logic as it adds development and testing time. So one must expect some
receivers conforming to the RFC will not have ability to discriminate
based on the MRD value, but all tolerate its presence.

I see other implications than the one Gorry cited for general purpose
MPEG-2 distribution systems.

These implications arise from the fact that PID values for payload
streams are free to be changed by MPEG-S TS equipment, provided the PSI
reflects the change.

I1: So, if the PID value of the ULE stream is changed by a multiplexer
<somewhere> in the distribution path, a receiver which was set up to
receive a stream with a certain PID value would have no way to verify
that the stream was a ULE stream. A receiver selecting and decoding this
PID could produce an output formatted per ULE rules that was not really
IP traffic. It could lead to bad data or result in intermittent loss of
data by down stream consumers (and the receiver that disembeds the IP
from the TS packets can legitimately signal the ULE stream on that PID
was fine here.)

I2: Without the MRD, a receiver cannot search the TS and locate the
stream(s) that are ULE sent using arbitrary PID values over standard
MPEG-2 compliant networks.

So I ask: 
Q1: What are the "valid reasons in particular circumstances to ignore a
particular item" in this particular case?

Q2: Is it to use a PID value that is set and communicated 'out of band'
to the receiver, and to force all equipment to not change that PID
value?  

If so, that could work for that case; but that is a private network, not
a general purpose one, and private networks can relax the requirement if
needed (these are voluntary RFCs after all). 

Q3: However, given the lack of robustness/reliability that results from
lack of the MRD, is the bit rate savings for not sending the MRD judged
worth the inability to identify ULE streams sent over 'normal' general
purpose MPEG-2 networks?

I posited need for a SHALL, with wording that excluded use MPEG-2
transport packets with a PMT (but which might not meet other MPEG-2 TS
requirements) and Adam reworded my posit to strictly apply to all use
(which I can support as well).

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 02 Aug 2005 15:53:24 +0200

Art, others, I'd like to respond to the SHOULD/SHALL thread as the WG Chair.

The reason an additional paragraph was inserted, was to associate a ULE
stream with a format descriptor that had been allocated by SMPTE. This now
forms one of three paragraphs in the introduction of the ULE encapsulation
spec. Looking at the thread, I believe the term "SHOULD" in the new para is
correct in the IETF sense, in that there are cases where the ULE protocol
could function without the information (e.g. A private network). This was
also discussed on the list earlier.

I'll present a slide with this text again at the IETF meeting tomorrow, and
if there are more views, I'll make sure they are discussed on this list.

Although the *encapsulation* work is now complete, the topics of addressing
and identification of the set of TS to be used is now very much a
work-in-progress. 

The AR document (see below) is intended to describe the process of
binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS).
In this latter context, the discussion seems valuable. The AR document needs
to explain why and how to use the PMT, when you need it, when you may not do
it, and what other protocol parameters need to be set to complete the
mappings for IPv4/v6 multicast/unicast etc. This discussion thread provides
useful inputs to this document, which we will try to now include in section
4.
http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ar-00.txt

Gorry