[R-C] [ledbat] LEDBAT vs RTCWeb

[Randell Jesup]

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.

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 Jesup
randell-ietf at jesup.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120426/11d2fa23/attachment.html>