Re: [R-C] [ledbat] LEDBAT vs RTCWeb
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@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@ietf.org To: harald@alvestrand.no CC: holmer@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@jesup.org
On Thu, Apr 26, 2012 at 7:12 PM, Randell Jesup <randell-ietf@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@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@ietf.org To: harald@alvestrand.no CC: holmer@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@jesup.org
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
On 4/27/2012 7:48 AM, Stefan Holmer wrote:
On Thu, Apr 26, 2012 at 7:12 PM, Randell Jesup <randell-ietf@jesup.org <mailto:randell-ietf@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").
A drop in delay alone isn't a trigger; it's a loss combined with a drop in delay. I.e. from a packet train point of view for 30ms packets: <- X - 31ms - X+1 - 31ms - X+2 - 31ms - X+4(!) - 31ms - X+5 That would be a fairly typical "signal" from a tail-drop router of buffer overflow - timing compressed by the queue. Also note the slope (increasing delay). If it were: <- X - 31ms - X+1 - 31ms - X+2 - 60ms - X+4(!) - 31ms - X+5 Then it would be much less "fishy". Note this is most effective in a constrained-channel case, perhaps somewhat less so in a contention-for-channel case - but constrained channel is the "normal" unloaded access-link or WiFi bottleneck. And in contention, it's still useful - you need to tune the amount a packet arrives "early", and I also added a rule to require multiple 'fishy' losses within a period (~2s) before it kicked in extra reduction, but that's a tuning/testing issue. For LEDBAT, as a scavenger protocol, it may make sense for it to respond to all drops by reducing more than TCP would. (Drops say either you have very short max queues (<~100ms), AQM, or other traffic has forced the queuing delay up to the limit - in either case you want to back off and yield. So long as all the scavengers drop roughly similar amounts, they should be fair among themselves in the super-short-queue (or AQM) case. In all other cases, LEDBAT would just get out of the way of foreground better/faster. It might reduce efficiency slightly in some cases, but I suspect not much, and the only case we really care about (for LEDBAT) is a non-fully-loaded channel. -- Randell Jesup randell-ietf@jesup.org
On Fri, Apr 27, 2012 at 8:45 PM, Randell Jesup <randell-ietf@jesup.org>wrote:
On 4/27/2012 7:48 AM, Stefan Holmer wrote:
On Thu, Apr 26, 2012 at 7:12 PM, Randell Jesup <randell-ietf@jesup.org <mailto:randell-ietf@jesup.org**>> wrote:
On 4/26/2012 11:49 AM, Nicholas Weaver wrote:
On Apr 26, 2012, at 8:05 AM, Rolf Winter wrote:
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").
A drop in delay alone isn't a trigger; it's a loss combined with a drop in delay. I.e. from a packet train point of view for 30ms packets:
<- X - 31ms - X+1 - 31ms - X+2 - 31ms - X+4(!) - 31ms - X+5
That would be a fairly typical "signal" from a tail-drop router of buffer overflow - timing compressed by the queue. Also note the slope (increasing delay). If it were:
<- X - 31ms - X+1 - 31ms - X+2 - 60ms - X+4(!) - 31ms - X+5
Then it would be much less "fishy". Note this is most effective in a constrained-channel case, perhaps somewhat less so in a contention-for-channel case - but constrained channel is the "normal" unloaded access-link or WiFi bottleneck. And in contention, it's still useful - you need to tune the amount a packet arrives "early", and I also added a rule to require multiple 'fishy' losses within a period (~2s) before it kicked in extra reduction, but that's a tuning/testing issue.
Ah, I didn't get that the loss was in the stream we receive. Then I completely agree, and this is one of the main advantages of having the loss-based detection at the receiver (which is currently not the case in the RRTCC proposal, although we do propose that as a future change in the I-D).
For LEDBAT, as a scavenger protocol, it may make sense for it to respond to all drops by reducing more than TCP would. (Drops say either you have very short max queues (<~100ms), AQM, or other traffic has forced the queuing delay up to the limit - in either case you want to back off and yield. So long as all the scavengers drop roughly similar amounts, they should be fair among themselves in the super-short-queue (or AQM) case. In all other cases, LEDBAT would just get out of the way of foreground better/faster. It might reduce efficiency slightly in some cases, but I suspect not much, and the only case we really care about (for LEDBAT) is a non-fully-loaded channel.
Yes, I agree.
-- Randell Jesup randell-ietf@jesup.org
participants (2)
-
Randell Jesup -
Stefan Holmer