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

["Mark Watson" <[e-mail]>]

All,

Just a quick note on the receiver buffering requirement due to FEC. As a
general rule, the receiver needs to know the largest difference in
sending time that there will be throughout the whole stream between an
FEC packet and any source packet that it protects. The playout must be
delayed by at least this amount to ensure that FEC packets don't start
arriving too late at some point in the stream.

This isn't specific to the FEC approach in this draft but is more
generally applicable. For example, in the 3GPP FEC work, we defined an
SDP attribute 'a=min-buffer-time' which specified this time in
milliseconds.

Regarding receiver capabilities: how do we know that the receiver
supports this FEC mechanism at all ? It should be sufficient here to
signal the minimum buffering time due to FEC and let the receiver decide
whether it can support this (although this is not just about receiver
capabilities, but also avoiding the case where receivers buffer too
much, which manifests as additional startup delay for the user).

A final aside: there are of course several other reasons for delay
between receiving a packet and playing it out - e.g. jitter buffers,
video buffers - and the interaction between these delays and the delay
due to FEC is complex and to a certain extent implementation dependent.
So, it is best that any signaling is defined as a property of the
stream, rather than having normative language about receiver buffering.
The property we want to capture is the "largest difference in sending
time that there will be throughout the whole stream between an FEC
packet and any source packet that it protects".

So, perhaps we could provide such a general attribute here, or we could
just reference this point in this draft and provide something more
general elsewhere.

Regards,

Mark 



-----Original Message-----
From: Cullen Jennings [mailto:[e-mail]] 
Sent: Monday, May 29, 2006 5:58 AM
To: Adam Li
Cc: Magnus Westerlund; IETF-AVT WG
Subject: Re: [AVT] Comments on draft-ietf-avt-ulp


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:

> Adam Li wrote:
>> 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.
>>> 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.
>> 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.
>
> 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 [phone]
> Torshamsgatan 23           | Fax   [phone]
> S-164 80 Stockholm, Sweden | mailto: [e-mail]

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

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