<br><br><div class="gmail_quote">On Fri, Apr 27, 2012 at 8:45 PM, Randell Jesup <span dir="ltr"><<a href="mailto:randell-ietf@jesup.org" target="_blank">randell-ietf@jesup.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 4/27/2012 7:48 AM, Stefan Holmer wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<br>
On Thu, Apr 26, 2012 at 7:12 PM, Randell Jesup <<a href="mailto:randell-ietf@jesup.org" target="_blank">randell-ietf@jesup.org</a><br></div><div><div class="h5">
<mailto:<a href="mailto:randell-ietf@jesup.org" target="_blank">randell-ietf@jesup.org</a><u></u>>> wrote:<br>
<br>
    On 4/26/2012 11:49 AM, Nicholas Weaver wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    On Apr 26, 2012, at 8:05 AM, Rolf Winter wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    <a href="http://www.infres.enst.fr/~drossi/DATA/PRJ-Ledbat+AQM.pdf" target="_blank">http://www.infres.enst.fr/~<u></u>drossi/DATA/PRJ-Ledbat+AQM.pdf</a><br>
<br>
    It seems like AQM causes LEDBAT to promote to behavior similar to TCP,<br>
    but with low delay.  Since it still seems fair, this is ok, but it's no<br>
    longer a background or scavenger flow, and applications using it need<br>
    to be aware they can impact"foreground"  flows if AQM is in play.<br>
    Perhaps applications need to be given awareness when LEDBAT detects<br>
    active AQM (if it can), and there's no"scavenger"  CC algorithm for AQM<br>
    that I know of.<br>
</blockquote>
    And the document makes that clear and I am not sure LEDBAT actually can detect AQM.<br>
</blockquote>
    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".<br>
<br>
    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.<br>
</blockquote>
<br>
    Correct, and that's a reasonable way to proceed - though it might<br>
    complicate slightly (and certainly change) the LEDBAT competing with<br>
    LEDBAT case.<br>
<br>
    In my delay-sensitive CC algorithm, I detected drops, and in<br>
    particular "fishy" drops where the end-to-end delay in the following<br>
    packet was lower by roughly the normal arrival interval, and would<br>
    take those as an indication that we should drop more substantially<br>
    than 'normal'.  This was targeted at tail-drop detection, especially<br>
    congestion spikes, but for a scavenger protocol the same idea could<br>
    apply to make it more responsive to AQM.<br>
<br>
<br>
Interesting idea indeed. Drops in delay will of course also happen when,<br>
say, one flow stops, so it's not only an indicator of tail-drop (even<br>
though the probability of tail-drop may be higher if the drop in delay<br>
is "fishy").<br>
</div></div></blockquote>
<br>
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:<br>
<br>
<- X - 31ms - X+1 - 31ms - X+2 - 31ms - X+4(!) - 31ms - X+5<br>
<br>
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:<br>
<br>
<- X - 31ms - X+1 - 31ms - X+2 - 60ms - X+4(!) - 31ms - X+5<br>
<br>
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.<br>
</blockquote><div><br></div><div>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).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.</blockquote>
<div><br></div><div>Yes, I agree.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Randell Jesup<br>
<a href="mailto:randell-ietf@jesup.org" target="_blank">randell-ietf@jesup.org</a><br>
</font></span></blockquote></div><br>