[AVT] AD questions on draft-ietf-avt-ulp

[Cullen Jennings <fluffy at cisco.com>]

I had several questions and concerns about this draft. I cc'd  
Jonathan as he was going to do an expert review. Likewise, Mark, as  
an review of this, do you  still have concerns that are not addressed  
that you think need to be fixed for this to go to RFC?

First of all, i raised a bunch of questions here - Do feel free to  
push back hard where I am confused, wrong etc. I have not been  
following this work, I am just reading it now, and have a somewhat  
limited amount of time to read all the background and really come up  
to speed on the whole topic. You will need to help educate me and I  
would be pleased to find out the document is fine and I am confused.

Major Items ------------

Is this backwards compatible with a device that does 2733. If not I  
have concerns about obsoleting it?

Can we have a way of signaling baseline and extended mode support? I  
would not want to have all old 2733 devices be required to support  
extended mode. Can we separate baseline and extended mode into two  
specifications.

I am unclear how a receiver wold know what order to apply SRTP/FEC  
processing. I am unconvinced there is a need for multiple ways of  
doing this. The security section needs discussion of problems with  
two time pads when doing this. It also will need security review with  
respect to two time pads issues from some security person.

Is specifying the mask and m(i) and L(k) in every packet the right  
design choice. This uses a lot of bandwidth and seems like  
information that would not need to be specified every time.

The document needs a sane and rational applicability statement. There  
are definitely deployment trade offs where this approach would not be  
the best way to go. Need to explain how and when this should be  
used.  Given we are forming a WG to deal with FEC, this document  
needs to also address when to use generic approaches vs these.

I am unclear on what level of reconstruction is provided or what we  
are tying to do with the multiple levels. For example, take the  
example in figure 5. Here 8 payloads are sent and 7 payloads worth of  
parity bits are sent so we are sending nearly as much FEC data as  
original data and introducing significant decode latency. Yet if  
payload 0 and 1 are lost, it does not seem like they can be  
reconstructed. I hope I am wrong here - it seems like with this  
amount of bits allocated to FEC we should be apply to loose any 3  
packets and still recover all the data. Please help me understand.  
Can both 0  and 1 be recovered?

It is unclear to me how the receiver will know if it  has enough  
buffer to decode the FEC stream that will be sent to it. It needs to  
know this when it decided if it wants the FEC stream or not.

The basic operation section that tries to give the overview of how  
the scheme works is very confusing for people not already familiar  
with the scheme. Let me be very blunt - I gave it to three different  
developers all familiar with RTP and none of them could figure out  
how this works or what it does. Part of the issue is that the term  
level is used before it ever introduced.


Minor Items ---------------

Is a m(i) of 48 bits enough for things like mpeg?

How does this work to FEC something where the next packet may not  
happen for a very long time like DTMF or text.

Given the packet overhead, would this be the recommended way to  
protecting say 20 ms G.729 audio packets in an interactive voice  
conversation.

Nice to point out some example audio codecs that benefit from ULP.

When doing FEC on an encrypted packet, the encryption is very likely  
to make ULP useless - should carefully consider and discuss.

Would there ever be a case to have both integrity protection and ULP?  
Seems weird.

I think that is the media is encrypted, then the FEC MUST be  
encrypted too ( not should ) and similarly with integrity.

In section 11, the discussion of changing media encryption keys and  
how that relates to decoding the FEC packets, seems, ah, wrong.  
Perhaps it is right but more is needed on this.

Section 12, 2nd para. This tells implementers they MUST do something.  
However, I have no idea what they need to implement here. We need to  
give advice on what they implementers need to do - as it is, it does  
not seem implementable.

The advice on using FEC and redundant encoding or separate stream is  
somewhat unsettling. First it say SHOULD do it as separate stream and  
provided no exception when you would not then goes on for a few  
section on telling you how to violate this SHOULD. Would be nice to  
have advice on when an implementation uses each one (or just define  
one way). I will note that from a bandwidth tracking for RSVP and  
flow set up for ICE point of view, redundant encoding has advantages.


Trivial Stuff ------------------

Section 16 mentions Hamming codes? Are they discussed elsewhere in  
the document. (Note I think Hamming codes are a good idea and  
suggesting making it clear how to use them not suggesting removing them)

Header of draft need to specify the RFCs it obsoletes.

Section 5 - the sentence ending in "the channel capacity is not fully  
utilized" make no sense to me. I don't think we mean the same things  
by channel capacity.

Section 7.3 - I don't think the timestamp setting is correct. I think  
you want the timestamp of packet the protected packet with the  
largest timestamp. Often you want to delay sending FEC packets after  
the final packet they protect so that burst channel errors have  
better chance of not killing the last packet and the FEC packet.

The term  "monotonically increasing"  has contention meanings - I  
would not use this term and instead just say what you mean.   (ie  
every FEC packet has a TS that is the same or larger than previous  
packets). I also don't think this will turn out to be true for FEC  
protected video.

When using 48 bit mask where is the low bit?

IANA registration - I don't think the change controller should be a  
WG as they get closed.

This document has a lot of advertising in it - for example it  
suggests ULP is useful place where Reed-Solomon is too  
computationally complex. Every codec type that I can think of where  
ULP will be useful requires complex transforms such as frequency  
space for audio or DCT approximation to frequency space for video  
that make the Reed-Solomon computation complexity look like a drop in  
the bucket. Are there codec that can use ULP that are used on devices  
where the extra complexity of Reed-Solomon would make a significant  
impact on the device?

I understand the desire to keep the title the same as the document  
this replaces but this is far from a generic scheme and I think a  
misleading title is worse that a changed title.





_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt