[R-C] [ledbat] LEDBAT vs RTCWeb

[Stefan Holmer]

On Thu, Apr 26, 2012 at 7:12 PM, Randell Jesup <randell-ietf at jesup.org>wrote:

>  On 4/26/2012 11:49 AM, Nicholas Weaver wrote:
>
> On Apr 26, 2012, at 8:05 AM, Rolf Winter wrote:
>
>  http://www.infres.enst.fr/~drossi/DATA/PRJ-Ledbat+AQM.pdf
>
> It seems like AQM causes LEDBAT to promote to behavior similar to TCP,
> but with low delay.  Since it still seems fair, this is ok, but it's no
> longer a background or scavenger flow, and applications using it need
> to be aware they can impact "foreground" flows if AQM is in play.
> Perhaps applications need to be given awareness when LEDBAT detects
> active AQM (if it can), and there's no "scavenger" CC algorithm for AQM
> that I know of.
>
>  And the document makes that clear and I am not sure LEDBAT actually can detect AQM.
>
>  One thought:  Active Queue management will be either ECN or early drop.  Which is a signal separate to the delay signal used which is "friendlier than TCP".
>
> In either case, the scavenger flow property might be, well, not fully maintained but at least encouraged by backing off more than conventional TCP would to the same signal.
>
>
> Correct, and that's a reasonable way to proceed - though it might
> complicate slightly (and certainly change) the LEDBAT competing with LEDBAT
> case.
>
> In my delay-sensitive CC algorithm, I detected drops, and in particular
> "fishy" drops where the end-to-end delay in the following packet was lower
> by roughly the normal arrival interval, and would take those as an
> indication that we should drop more substantially than 'normal'.  This was
> targeted at tail-drop detection, especially congestion spikes, but for a
> scavenger protocol the same idea could apply to make it more responsive to
> AQM.
>

Interesting idea indeed. Drops in delay will of course also happen when,
say, one flow stops, so it's not only an indicator of tail-drop (even
though the probability of tail-drop may be higher if the drop in delay is
"fishy").


>
> Basically, for a scavenger protocol any drop is a warning that either you
> or someone else has pushed a queue up to tail-drop levels, or that AQM is
> in play.  In either case you should back off, and if you back off more than
> TCP would, that that allows TCP to retain it's foreground advantage while
> not hurting scavenger performance (much?) when it competes with itself.  It
> may want to use drops to develop an estimate of the bottleneck queue depth
> (if less than the target value), to help avoid triggering tail-drops when
> not competing with TCP.  (I.e. a target of 100ms doesn't make sense if the
> bottleneck queue is 50ms deep - and you can consider AQM really the
> equivalent of a minimal-depth queue at the bottleneck.)  Such an estimate
> (which would be near 0 for AQM) might let it properly handle AQM, which is
> an idea which might help in RRTCC as well.
>
> For those looking for the "RRTCC" (horrible name :-)  draft, here's the
> latest:
>
> http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-02
>
>
> From: harald at alvestrand.no
>
> This is mainly a maintenance update. No changes to the algorithm, but
> reworded to show how it can be applied across multiple SSRCs at one time.
>
>                  Harald
>
> -------- Original Message --------  Subject: New Version Notification for
> draft-alvestrand-rtcweb-congestion-02.txt  Date: Wed, 25 Apr 2012
> 05:03:35 -0700  From: internet-drafts at ietf.org  To: harald at alvestrand.no  CC:
> holmer at google.com
>
> A new version of I-D, draft-alvestrand-rtcweb-congestion-02.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository.
>
> Filename:	 draft-alvestrand-rtcweb-congestion
> Revision:	 02
> Title:		 A Google Congestion Control Algorithm for Real-Time Communication on the World Wide Web
> Creation date:	 2012-04-25
> WG ID:		 Individual Submission
> Number of pages: 17
>
> Abstract:
>    This document describes two methods of congestion control when using
>    real-time communications on the World Wide Web (RTCWEB); one sender-
>    based and one receiver-based.
>
>    It is published to aid the discussion on mandatory-to-implement flow
>    control for RTCWEB applications; initial discussion is expected in
>    the RTCWEB WG's mailing list.
>
>
> --
> Randell Jesuprandell-ietf at jesup.org
>
>
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120427/aa07b392/attachment.html>