Subject: [AVT] Comments on draft-ietf-avt-ulp

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 26 May 2006 16:10:29 -0400

I took a look at draft-ietf-avt-ulp at Cullen's request. Though I'm 
familiar with RFC 2733 I have been pretty distant from the ULP work. So, 
my apologies if any of these issues were discussed already.

Comments below:

 > For audio streams, the bitstreams generated by many of the new audio
 >    codecs also contain data with different classes of importance. These
 >    different classes are then transmitted in order of descending
 >    importance. Applying more protection to the beginning of the packet
 >    would also be beneficial in these cases.

The motivation for audio here is weak. Can you reference specific audio
codecs for which this is true? It also seems like the value for audio is
significantly hampered since there are usually multiple frames per
packet. Thus, the protection would need to be scattered throughout the 
packet, not in the beginning. If there is really no applicability to 
audio it should state that.

 > Even for uniform-
 >    significance audio streams, special stretching techniques can be
 >    applied to the partially recovered audio data packets.

What is 'special stretching techniques'? This should be explained or 
discarded.

 > In cases
 >    where audio redundancy coding is used, more protection should be
 >    applied to the original data located in the first half of the
 >    packet. The rest of the packet containing the redundant copies of
 >    the data does not need the same level of protection.

Sure, redundancy coding is already a form of FEC. There is little 
incentive to layer yet another layer of FEC ontop of it. Thus, this use 
case seems like a stretch.

 >  This approach has the advantage that media packets can be
 >    interpreted by receivers which do not support FEC. The overhead for
 >    using the FEC scheme is only present in FEC packets, and can be
 >    easily monitored and adjusted by tracking the amount of FEC in use.

This is true, but it doesn't mean that a sender can just send FEC 
packets without knowing if the receiver supports them. FEC needs to be 
negotiated through SDP just like any other media encoding. Consequently, 
each implementation still needs to support a mode where the other side 
knows about FEC, and a mode where it doesn't.

 > The packets of the two modes of FEC are distinguished by the
 >    Extension bit carried in-band in the FEC header. External signaling

This terminology - 'extension bit in the FEC header' - is very similar 
to the extension bit in the RTP header. I'd suggest using a different 
term from 'extension bit'.

 > Payload type: The payload type for the FEC packets is determined
 >    through dynamic, out-of-band means. According to RFC 3550 [1], RTP
 >    participants that cannot recognize a payload type must discard it.
 >    This provides backwards compatibility.

Yeah, but as above, its still going to be negotiated anyway.

 > The FEC mechanisms can then
 >    be used in a multicast group with mixed FEC-capable and FEC-
 >    incapable receivers, particularly when the FEC protection is sent as
 >    redundant encoding (see Section 14). In such cases, the FEC
 >    protection will have a payload type which is not recognized by the
 >    FEC-incapable receivers, and will thus be disregarded.

Ah, thats interesting. I think this backwards compatibility story is 
really just for multicast then. That should be clarified above.

 >   This header is 12 or 16 octets, depending on whether the long-mask
 >    flag (the L bit, see below) is set. The format of the header is
 >    shown in Figure 2 and consists of extension flag (E bit), long-mask

Figure 3 (Figure 3 is actually listed twice)

 >    a. A media packet SHALL be protected only once at each
 >          protection level higher than level 0. A media packet MAY be
 >          protected more than once at level 0 by different packets,
 >          providing the protection lengths of level 0 of these packets
 >          are equal.

I don't understand this rule. Certainly in the basic mode a packet can 
be protected by many FEC packets. Why does this change when unequal 
protection is applied?

 >   0                   1
 >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
 >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >    |       Protection Length       |
 >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >
 >    Figure 3: ULP Level Header Format (Level 0)

The reason for the different format for level 0 is never explicitly 
called out. Its because the other information that is needed - the mask 
in particular - is taken from the FEC header. I think this is somewhat 
confusing and non-intuitive. One would think that there would be a 
common FEC header with the SN-base and other data, followed by a header 
for each level, with the same format in each case. I'm not sure why this 
format was chosen, but its unintuitive.

In a related comment, the draft describes extended and basic modes as if 
they were radically different. But they're really not. Basic mode is 
identical to extended mode with one level (level 0), where the length is 
the length of the largest packet. Indeed, one could do away with basic 
mode entirely by specifying it that way. The cost would be the extra 
length field in each packet. Is that signficant? Doesn't seem so.

 >  b. For a media packet to be protected at level p, it MUST also
 >          be protect at level p-1 in any FEC packets. Please note that
 >          the protection level p for a media packet can be in a FEC
 >          packet that is different from the one which contains
 >          protection level p-1 for the same media packet.

Hmm, I also don't understand this constraint. A MUST implies that 
something breaks if you don't follow it. But, clearly nothing breaks 
since FEC is optional generally speaking. The motivation here needs to 
be explained, or the requirement dropped.

 >     c. If an ULP FEC packet contains protection at level p, it MUST
 >          also contain protection at level p-1. Note that the
 >          combination of payload packets that are protected in level p
 >          may be different from those of level p-1.

I believe this constraint is because the level is never actually 
EXPLICITLy signaled. Rather, the level increases by 1 for each FEC 
header in the packet, starting at 0. That should be clearly stated.

 >  For Protection Level n (n = 0, 1, ...), only Ln octets of data are
 >    set as the FEC Level n payload data after the Level n ULP header.
 >    The data is the Ln octets of data starting with the (Sn + 11)th
 >    octet in the FEC bit string, where:
 >
 >    Sn = sum(Li : 0 <= i < n).

Ah, interesting. THis might explain why you require that, if a packet is 
protected at level n, its also protected at n-1. Without that, you would 
only be able to recover stripes of information. That may actually be OK; 
indeed per my comments above that might even be useful for audio codecs. 
In any case, this particular fact - that each level contains some number 
of bytes beyond the previous level - is not clearly called out in the 
overview. It needs to be.

 >    2.  For the FEC packet in T, compute the FEC bit string by
 >           concatenating the first 80 bits of the FEC header with the
 >           FEC payload.
 >
 >       3.  If any of the protected bit strings generated from the media
 >           packets are shorter than the FEC bit string generated from
 >           the FEC packet, pad them to be the same length as the FEC bit
 >           string generated from the FEC. The padding of octet 0 MUST be
 >           added at the end of the protected bit string.
 >
 >       4.  Calculate the recovery bit string as the bitwise exclusive OR
 >           of the protected bit string generated from all the media
 >           packets in T and the FEC bit string generated from all the
 >           FEC packets in T.

This text is inconsistent on whether there can be just one, or one or 
more FEC packets. I believe its more than one.

 > The recovery bit string of the current protection level as
 >           generated above is combined with the recovery bit string of
 >           all the other levels to form the (fully or partially)
 >           recovered media packet. Note that the recovery bit string of
 >           each protection level MUST be placed at the correct location
 >           in the recovered media packet for that level based on
 >           protection length settings.

You need to say how they are combined. It is through concatenation, I 
believe.

* Section 11 is really confusing on what the protocol ACTUALLY 
specifies. Its written more like a design discussion. Which approaches 
are in fact legal and supported?

 > 15.1. FEC as a Separate Stream
 >
 >    In the case discussed in this subsection, the FEC packets are sent
 >    as a separate stream. This means that they can be sent on a
 >    different port and/or multicast group from the media.
 >
 >    Just like any media stream, the port number and the payload type
 >    number for the FEC stream is conveyed in its m line in the SDP.
 >    There is no static payload type assignment for FEC, so dynamic
 >    payload type numbers MUST be used. The binding to the number is
 >    indicated by an rtpmap attribute. The name used in this binding is
 >    "ulpfec". The address that the FEC stream is on is conveyed in its
 >    corresponding c line.
 >
 >    The association relationship between the FEC stream and the payload
 >    stream it protects is conveyed through media line grouping in SDP
 >    (RFC 3388) [5] using FEC semantics (RFC yyyy) [6]. The FEC stream
 >    and the protected payload stream forms an FEC group.

I don't really understand why the FEC grouping spec is a separate 
specification. Typically the SDP mechanisms for a payload format are in 
the same draft as the payload format. I think its harder to read when 
they are separated, especially since there is such a detailed example of 
the grouping mechanism here.

 >  The presence of two a=group lines in this SDP indicates that there
 >    are two FEC groups. The first FEC group, as indicated by the
 >    "a=group:FEC 1 2" line, consists of stream 1 (an audio stream using
 >    PCM) and stream 2 (the protecting FEC stream). T

Does this mean that the FEC stream is always the last stream? Does this 
mean that FEC groups can only ever have two RTP streams? I suspect this 
is specified in the other draft, but given the level of detail here it 
needs to be mentioned or else the drafts combined.

 > If the
 >    answerer accepts the usage of FEC, the answer simply accepts the FEC
 >    RTP session and the grouping in the offer by including them in the
 >    answer.

Hmm. That doesnt seem right. I don't think there is a requirement to 
actually use the same mids (in fact, I don't think you can require that) 
in the answer. So, I think what this is saying is that, the set of 
streams grouped together in an answer must match the set of streams 
grouped together in the offer, even if the mids differ. Or something 
like that. This requires more detailed spceification. Whether parameters 
are declared or negotiated via O/A is a constant source of confusion and 
needs to be very clear.

* Section 16 seems out of place. Much of it repeats the introduction, 
and the rest compares ULP with UXP. A reference to UXP is not even 
given, and I think the group isn't moving forward with it (though not 
100% sure) so what is the point in the comparison?

* Sections 14 and 15 seem really similar, not clear why they are separate.

* Sections 14 and 15 should precede the IANA and security considerations 
sections - they are fundamental parts of the protocol spceification.

* Nothing in the document is said about RTCP. For example, can ULP be 
applied to recovery RTCP packets? Are the RTCP poackets in the FEC 
stream regular RTCP or recovery packets themselves? I believe that they 
are regular RTCP packets and there is no recovery of RTCP, but this 
should be stated.

* Per above the protocol is grossly underspecified for usage with SRTP, 
since the final mechanism is not described and there are no parameters 
defined for signaling what the order is for FEC and SRTP. This needs to 
be fixed.

* I don't think the mechanism is backwards compatible with the previous 
version of the specification; that should be called out

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Adam Li" <[email-masked]>
Date: Sun, 28 May 2006 21:09:37 -0700

Hi Jonathan, all,

Thanks a lot for the review and the comments. I will incorporate them in the
revision. A few questions about some of them here, and also would like to
hear instructions from the Directors and Chairs.

> length field in each packet. Is that signficant? Doesn't seem so.

Very good questions.

(1) About having separate baseline mode and extended mode. Originally the
ULP is designed as an extension of RFC2733. As the draft evolves, the
compatibility with RFC2733 is no longer an issue. The difference between the
baseline mode and extended mode with only one level is 16-bit length field.
If we do not mind that extra 16-bit, we can simple remove the baseline mode
as Jonathan said. That would greatly simplify the specification and
implementation as well.

(2) About having different header for level 0 and higher levels. This stems
from the issue above of having two separate modes. If we had only one mode,
a natural design would be to move bit mask to level header. This would have
exactly the same overhead, and we would have a unified header for all
levels.

So the question for the Director and Chair is:

Shall we do away with the baseline mode?

with a cost of 
    * where it was baseline mode, one may have to pay 16-bit more 
      and use the extended mode with single level;

With a gain of
    * simpler specification (only one mode);
    * unified level header (for all levels);
    * simpler implementation.

Please advice. Thanks a lot.

Adam

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 29 May 2006 10:04:29 +0200

> Please advice. Thanks a lot.

Hi,

I for a removal of the baseline mode and have a unified structure. I 
agree that it clearly has advantages in its simplification.

On a related note: This spec is going to be replacing rfc2733 and thus I 
think we should have a possibility to run it in a mode that haves the 
same capabilities and no extra complexities. Thus I wonder if we should 
add a signalling parameter that restricts the FEC operations to only 0 
levels.

Also, if I remember correctly Cullen also raised the issue if any 
parameters should exist for indicating the needed buffering etc in the 
receiver to do the recovery. So I also wonder about if such should be 
added. The general problem in this space is defining required support so 
that implementations can interoperate.

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: Cullen Jennings <[email-masked]>
Date: Mon, 29 May 2006 05:57:45 -0700

Hi Adam,

These are excellent questions. I've been trying to also make the  
right trade off between just calling this "good enough" and using up  
additional time to make it better. My knee jerk reaction is that I  
like the simplification you propose and signaling of level 0 only -  
seems this would be easy to do and allow for simpler interoperable  
implementations without loosing the functionality possible if both  
sides supported more than level 0. If you made is so supporting at  
least level 0 was a MUST implement and supporting levels beyond that  
was not mandatory to implement it would make it closer to the same  
complexity level of the FEC scheme it is deprecating.

I suspect that my concerns about if the receiver had enough before  
and other resources might just be best ignored at this stage. Do give  
them some thought and if they can be easily satisfied, even in some  
minimal way, that is great but if folks believe that specifying that  
would add a level of complexity that was just too much complexity for  
too little gain in real interoperability - don't be afraid to tell  
it's a lame idea :-)

Is there some chance you and I, the chairs, and any others that wish  
to join could have a short phone call to figure out the pros and cons  
of the best path forward here then see if it is acceptable to the  
folks on the list? I suspect that some of the answer to this is going  
to be around how much work you are willing to do. I am very much on  
the path of getting this done soon not sending it back for another  
year of modifications in the WG.

Cullen

On May 29, 2006, at 1:04 AM, Magnus Westerlund wrote:

>> with a cost of     * where it was baseline mode, one may have to  
>> pay 16-bit more       and use the extended mode with single level;
>> With a gain of
> I for a removal of the baseline mode and have a unified structure.  
> I agree that it clearly has advantages in its simplification.
>
> On a related note: This spec is going to be replacing rfc2733 and  
> thus I think we should have a possibility to run it in a mode that  
> haves the same capabilities and no extra complexities. Thus I  
> wonder if we should add a signalling parameter that restricts the  
> FEC operations to only 0 levels.
>
> parameters should exist for indicating the needed buffering etc in  
> the receiver to do the recovery. So I also wonder about if such  
> should be added. The general problem in this space is defining  
> required support so that implementations can interoperate.
>
>
> Cheers
>
> Magnus Westerlund
>