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

["Adam Li" <[e-mail]>]

One thing we can add is to signal that only short mask will be used.

> -----Original Message-----
> From: Mark Watson [mailto:[e-mail]]
> Sent: Monday, June 05, 2006 11:19 AM
> To: Cullen Jennings; Adam Li
> Cc: Magnus Westerlund; IETF-AVT WG
> Subject: RE: [AVT] Comments on draft-ietf-avt-ulp
> 
> 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