Subject: RE: ULE encryption Support.

From: "Allison, Art" <[email-masked]>
Date: Mon, 1 Mar 2004 10:21:24 -0500

Thanks for the post about layering, Gorry.. it does seem that we don't stick
to the 'right' place in the stack in all out posts. 
As far as the place in the layers for duplication of transport packets, that
seems to me to be at the MPEG-2 transport layer, not above it.   I read
Gorry pointing to the first phrase of #2 when he says this group is focused
on #2 as the rest is explanation of the underlying protocol.

I agree that the layer just above the MPEG-2 transport is the focus of this
group.

Given that focus, before adding an additional protection means at this
layer, it seems that the person suggesting such should bear the burden of
asserting what improvement in BER can be expected over that provided by the
lower and higher layers.  I am skeptical that one can add error correction
at this layer that any significant benefit in a real world RF channel.  I
say this because:
If the RF channel outage/fade/interference is large enough to corrupt data
beyond the RF recovery means ability to correct, it is unlikely that error
correction will help (theoretically one would need to have a large temporal
spread of data with error correction overhead to cover such a condition -
which would be a significant complication with latency impact).  
It is very unlikely that a bad packet is actually in the data and falsely
signaled as good, (i.e., the MPEG-2 packet error bit not set when the packet
is bad).  I don't know the FEC in OFDM or QPSK systems in use; but the FEC
in 8VSB has a lower false-positive error rate than CD-ROM. I would expect
that to be ~true of any RF layer FEC.  

So additional error detection at the layer in this group's scope seems
unlikely to help in the severe outage case and unlikely to help in the
very-low-probability case where the complex pattern of bit errors would
cause a false positive. 

In just what condition/case does it help? And by how much BER improvement?
 
Art
::{)>
Art Allison
Director Advanced Engineering
NAB
1771 N St NW
Washington DC 20036
202 429 5418

-----Original Message-----
From: Gorry Fairhurst [mailto:[email-masked]]
Sent: Monday, March 01, 2004 8:26 AM
To: [email-masked]
Cc: Alain RITOUX
Subject: Re: ULE encryption Support.

Just a word or two, to try and help people establish the correct 
context, to communicate...

1) FEC coding is used as a part of physical layer for most media, i.e. 
below the MPEG-2 bit stream.
This type of FEC is NOT the concern of this group and is sepcified by 
others.

2) Coding may also be used above the MPEG-2 TS layer, in some scenarios 
to further improve robustness to
loss (i.e. corruption of the MPEG-2 TS packet stream).  The duplication 
method, discussed in the
"continuity counter" thread is an example of this - albeit rather crude 
from a coding point of view,
and within the transport stream. A "recent" extension to MPE, added the 
optional ability to do more
powerful FEC coding as a part of the encapsulation.

3)  FEC coding may also be done above the transport layer, to protect 
the end-to-end communication
from the effects of packet loss. For more details of such schemes see 
the AVT and RMT WGs of the IETF.

So, (2) is what relates to this WG.

Gorry

---

From: Alain RITOUX <[email-masked]>
Date: Mon, 01 Mar 2004 16:39:43 +0100

> on #2 as the rest is explanation of the underlying protocol.

I defintively agree.

All proposition that I made, where about the possibility of Extension
Headers, and its mechanisms.

The reference about encryption and/or FEC was for me JUST an example of
usage. It DOES NOT imply support for the FEC / encrpyt  / whatever
function at this level. I should have kept the 2 subjects more
separated. In fact :
  - for FEC, I have no expertise on that subject, and have no opinion.
  - for Encrypt, I believe it is not in the correct layer to do this.

Regards.
Alain.

-- 
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com