<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 4/26/2012 11:49 AM, Nicholas Weaver wrote:
<blockquote
cite="mid:2CB80A7D-2F91-4576-8116-FF171EB82E2C@icsi.berkeley.edu"
type="cite">
<pre wrap="">On Apr 26, 2012, at 8:05 AM, Rolf Winter wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""><a class="moz-txt-link-freetext" href="http://www.infres.enst.fr/~drossi/DATA/PRJ-Ledbat+AQM.pdf">http://www.infres.enst.fr/~drossi/DATA/PRJ-Ledbat+AQM.pdf</a>
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.
</pre>
</blockquote>
<pre wrap="">
And the document makes that clear and I am not sure LEDBAT actually can detect AQM.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<br>
Correct, and that's a reasonable way to proceed - though it might
complicate slightly (and certainly change) the LEDBAT competing with
LEDBAT case.<br>
<br>
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.<br>
<br>
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.<br>
<br>
For those looking for the "RRTCC" (horrible name :-) draft, here's
the latest:<br>
<br>
<a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-02">http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-02</a><br>
<br>
<br>
From: <a class="moz-txt-link-abbreviated"
href="mailto:harald@alvestrand.no">harald@alvestrand.no</a><br>
<br>
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.<br>
<br>
Harald<br>
<br>
-------- Original Message --------
<table class="moz-email-headers-table" border="0" cellpadding="0"
cellspacing="0">
<tbody>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject: </th>
<td>New Version Notification for
draft-alvestrand-rtcweb-congestion-02.txt</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date: </th>
<td>Wed, 25 Apr 2012 05:03:35 -0700</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">From: </th>
<td><a class="moz-txt-link-abbreviated"
href="mailto:internet-drafts@ietf.org">internet-drafts@ietf.org</a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">To: </th>
<td><a class="moz-txt-link-abbreviated"
href="mailto:harald@alvestrand.no">harald@alvestrand.no</a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">CC: </th>
<td><a class="moz-txt-link-abbreviated"
href="mailto:holmer@google.com">holmer@google.com</a></td>
</tr>
</tbody>
</table>
<br>
<br>
<pre>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.
</pre>
<br>
<pre class="moz-signature" cols="72">--
Randell Jesup
<a class="moz-txt-link-abbreviated" href="mailto:randell-ietf@jesup.org">randell-ietf@jesup.org</a></pre>
</body>
</html>