Subject: Re: [rmcat] New Version Notification for draft-singh-rmcat-adaptive-fec-01.txt

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 1 Dec 2014 10:28:38 +0100

Hi Randell,

sorry, very late reply to this mail, anyway:

FEC also helps you (in case of competing with any kind of cross traffic) to probe for getting a larger share of the rate than you currently have. If you don’t try to send more data than you currently send, you might just grab the left-over bandwidth instead of ‚your fair share‘ (what ever that means). And in some cases interactive media traffic might even be more important than the other traffic on the same link; so it might even be okay to get a slightly larger share and potentially provide a better video quality. For this kind of probing, you need to increase your sending data rate but you don’t want to increase the video rate because you don’t want to switch forth and back. Does this makes sense to you?

Mirja

> Am 09.11.2014 um 20:34 schrieb Randell Jesup <[email-masked]>:
> 
> On 10/24/2014 12:00 PM, Varun Singh wrote:
>> Name: draft-singh-rmcat-adaptive-fec
> 
> Following up on comments in the interim:
> 
> 1) Adaptive FEC helps you (compared to just increasing encoder rate) in two cases:
>   a) very short queue or some form of AQM, where going over the available bandwidth rapidly results in loss instead of queuing delay
>   b) Very delayed encoder rate changes, or (maybe) very low frame rate combined with a close-to-rate pacing buffer.  These would make it hard to probe without problems backing off fast enough.
> 
>  It does not help you in the "normal" case.
> 
> 2) This implies you should use it opportunistically when the current conditions imply the cases in #1 are true (when you see that increase in sending rate results in loss and not delay, inferring this is AQM or very short queuing (or an already-full-queue).  You should also verify and leave this mode if the prerequisites change, since the actual bottleneck could move from one link to another during a call
> 
> -- 
> Randell Jesup -- rjesup a t mozilla d o t com

---

From: Varun Singh <[email-masked]>
Date: Mon, 1 Dec 2014 13:08:20 +0200

Hi Randell,

On Sun, Nov 9, 2014 at 9:34 PM, Randell Jesup <[email-masked]> wrote:
>    a) very short queue or some form of AQM, where going over the available
> bandwidth rapidly results in loss instead of queuing delay
>    b) Very delayed encoder rate changes, or (maybe) very low frame rate
> combined with a close-to-rate pacing buffer.  These would make it hard to
> probe without problems backing off fast enough.
>
> 2) This implies you should use it opportunistically when the current
> conditions imply the cases in #1 are true (when you see that increase in

While it will work when #1 is true, however, FEC is also used for
error-resilience, especially when NACKs wont work, i.e., the time
1.5*RTT will be longer than the size of the dejitter buffer, and the
retransmitted packet may not be sent for playback. So most end-systems
that observe more than 50ms OWD, will enable FEC by default (in an
attempt to meet 150-200ms end-to-end delay), the adaptive FEC is
attempting to couple these two aspects.

> sending rate results in loss and not delay, inferring this is AQM or very
> short queuing (or an already-full-queue).  You should also verify and leave
> this mode if the prerequisites change, since the actual bottleneck could
> move from one link to another during a call
>
> --

-- 
http://www.netlab.tkk.fi/~varun/

---

From: Randell Jesup <[email-masked]>
Date: Fri, 05 Dec 2014 09:46:51 -0800

> attempting to couple these two aspects.

When to use non-adaptive FEC is a tricky question, since you're trading 
lower quality all the time for less impact when there's a loss (i.e. not 
having to freeze the stream for a frame or two, or in more extreme cases 
not having to send an iframe recovery).  My point was to adaptive FEC 
for probing only really helps if probing is likely to cause loss, or if 
the system reaction time to encoder bitrate changes is too slow.  
Certainly if you get loss and RTT/delay is high enough, FEC can help.

-- 
Randell Jesup
[email-masked] (remove -ietf for personal mail)