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

From: Cullen Jennings <[email-masked]>
Date: Mon, 15 May 2006 01:40:49 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 15 May 2006 16:28:43 +0200

Hi Cullen,

I will provide my view on your comments. However I would appreciate if 
you in the future where a bit more specific about what your comments 
applies to.

Cullen Jennings wrote:
> 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?

It is not backwards compatible with RFC 2733. The reason why it is not 
is that RFC 2733 breaks RTP processing. So we really like to say: Hey, 
RFC 2733 is broken stop using it. Use this instead if RFC 2733 would 
have worked for you.

> extended mode. Can we separate baseline and extended mode into two 

Sure, you can have it for the price of creating less interoperability. 
As we are not backwards compatible with RFC 2733, there is no deployed 
base to consider. I don't think the WG appreciate to do the work of 
splitting these specifications. This spec is something that should have 
complete years ago.

> 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.

The order is defined by an SRTP parameter, see RFC 3711. Secondly I 
don't see how a payload can result in two time pad issues. Although we 
can send the same or similar data in multiple packets, but that do not 
create a two time pad issues. The two time pad issues with SRTP is if 
multiple payload are encrypted using the same key and IV. To my 
knowledge the presented usage of ULP does not create any such issues.

I agree that security review is good. I have expected that the SRTP 
people on the list has taken a look. However I guess that is a bit 
optimistic without explicit requests. So please solicit further review.

> design choice. This uses a lot of bandwidth and seems like information 
> that would not need to be specified every time.

That can of course be discussed, but we was primarily doing a RFC 2733 
replacement.

> 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.

What part of the statement do you not fine sane? Please consider that 
this statement was written when UXP was developed and a competitor with 
ULP. If anything I think we should drop anything talking about other 
mechanism not yet defined. I don't think we can talk about comparing 
this with FECFRAME, because that solutions properties are not yet known. 
So if anything it should be focused on what it is capable of.

> 
> 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?

I think you are correct, that loss of payload packet 0 an 1 result in a 
failure to recover 0 and 1 at level 0, 0,1,2, and 3 at level 1 and 0-7 
at level 2.

> 
> 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.

There is no information on this. The 48 bit mask put certain 
restrictions on the buffer size.

> 
> 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.

Okay, if you mean section 3, then I guess it can be improved. Is the 
real description understandable so that one can basically delete this 
section?

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

I would claim that your statement provides to little info to be 
evaluated. 48 bits are enough for most applications in the kilo bit 
range, for applications in the megabit range it is probably not enough.

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

That is an interesting thing. But if no packet is sent, you can change 
your FEC encoding and send a repair packet based on a timer. Please 
remember that ULP can support packet replication by stating it is the 
XOR of a single packet.

> protecting say 20 ms G.729 audio packets in an interactive voice 

In those cases I think RFC 2198 is a better way, even when using it to 
duplicate the complete frames.

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

This depends on the encryption algorithm, if block cipher is used, yes. 
For stream ciphers, no. But you are correct that this should be included 
in the security consideration.

> Would there ever be a case to have both integrity protection and ULP? 

Yes, only if partial protection is available will it make sense.

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

Yes, but then one needs to state the exception if one applies the FEC 
afterwards.

> 
> 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.

I agree it is a bit unclear. There is some issues with caching of keys 
if one applies FEC to already encrypted packets, as the key will be 
needed after recovery. There is also the interaction between the two 
streams if encryption is applied to one source data RTP session and one 
with FEC data. If the key changes are used for access restriction then 
such changes may have strange results unless the keys in both session 
are changes at the same time.

> give advice on what they implementers need to do - as it is, it does not 
> seem implementable.

What, to have a knob on your FEC encoder to determine who much output 
you get. I think it is implementable, however not very simple.

> 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.
> 

Okay, agreed, it probably should explain in which cases breaking the 
should may be motivated.

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

Actually this is by the IESG agreed sentence that has been used the last 
few years on all of AVTs payload formats. The thing is that it reverts 
back to the IESG if the WG is closed.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: "Adam Li" <[email-masked]>
Date: Mon, 15 May 2006 16:45:24 -0700

Hi Cullen,

Thanks for the comments. I would like to have a small clarification on one

> Can both 0  and 1 be recovered?

Here is Figure 5 from the draft:

         Payload Packet #  |  FEC packet which protects at level
                           |       0           1           2
      ---------------------+---------------------------------------
                0          |       0           1           3
                1          |       0           1           3
                2          |       1           1           3
                3          |       1           1           3
                4          |       2           3           3
                5          |       2           3           3
                6          |       3           3           3
                7          |       3           3           3

   Figure 5: An example of protection combination

The detail is explained in the paragraphs following the figure in the draft.
The scenario described is having 8 payload packets sent (as you mentioned). 

However, there are only 4 FEC packets (not 7) protecting these 8 payload
packets. Further more, the overhead is not 4/8 but something smaller
(depending on settings as explained below).

For simplicity, let's assume all the payload packets are of the same size.
Then the above scenario can also be described with the following diagram
similar to those used in the example section (P1 refers to payload #1, F1
refers to FEC #1, and so on):

P0: #############################################################
P1: #############################################################
F0: 00000000
P2: #############################################################
P3: #############################################################
F1: 00000000111111111111111
P4: #############################################################
P5: #############################################################
F2: 00000000
P6: #############################################################
P7: #############################################################
F3: 0000000011111111111111122222222222222222222222222222222222222

The 0's are the protection level 0, 1's for level 1, and 2's for level 2.
The overhead depends on the settings and packet sizes. For example, if all
payload packets are the same length, and level 0 is 15% of the overall
length, the level 1 is 25% of the overall length, then the FEC to payload
ratio is 1.7:8, or an overhead of 17.5%.

Secondly, you are right that if both P0 and P1 are lost, they can not be
recovered. That is 2 / 9.7 (or 20.7%) data lost. If the lost packets are P0
and P2 instead, both of these can be recovered to level 0, or 15% recovery
of the lost data in this case. If the lost packets are P0 and P4 instead,
then both of the lost packets can be recovered to level 1, or 40% recovery
of the lost data in this case. This can be useful for the payload where the
partial data can be used to reconstruct and conceal for most of the less
important data that is un-recovered.

Adam

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 16 May 2006 16:30:54 +0200

Ok, thanks for working with me on this - some of my original comments  
are clearly off base.
I'm still confused ...

Let's say all the payload packets each have 10 octets of content and  
we are protecting the full packet. I was thinking that F0 would also  
be 10 octets? And if level 1 as protecting full packet F1 would have  
10 octets for the "0" protection and another 10 octets for the "1"  
protection. Do I have this right?

---

From: "Adam Li" <[email-masked]>
Date: Tue, 16 May 2006 11:35:26 -0700

Hi Cullen,

Thanks for the question.

> protection. Do I have this right?

The data can only be protected at one level, according to the three
protection setting rules in Section 7.5 (above Figure 5). For example, if
the 10 octets are protected by level 0, it must not be protected by level 1
again. Putting two protections in the same packet is usually less than ideal
because both protections are lost at the same time if the packet they are in
is lost. In additional, signaling such complex protection schemes will need
a great deal of bits for info (such as number, offset, and length) for each
_protected_ data (instead of each _protecting_ data, or FEC data). Each
protecting data (or FEC data) is protecting a group of protected data.

According to the same rule set, the data may be protected by multiple
packets at the same level (this applies to baseline mode and level 0 of
extended mode). In the example you mentioned, it is illustrated in the
following:

P0: #####
P1: #####
F0: 00000      -> 00000 = P0 XOR P1
P2: #####
P3: #####
F1: 00000      -> 00000 = P0 XOR P1 XOR P2 XOR P3

Note that here P0 is protected by both F0 and F1. Also note, in this case F0
and F1 must have the same protection length at level 0 (this is also
specified in the rule set).

Adam