Subject: [iccrg] Fwd: Review of draft-khademi-alternativebackoff-ecn-01.txt

From: Michael Welzl <[email-masked]>
Date: Sat, 19 Dec 2015 11:29:22 +0100

Hi Bob,

Very sorry for the delay in getting back to this!
Taking a look at the thread again, rather than answering every single detail in line, I think it’s more efficient to answer in a general, summarized way here.

Your criticism seems to consist of 3 major parts:

1) style issues, specifics about how we phrase things (overstating benefits). Thanks for your comments there; we will incorporate several of them in the next update.

2) ABE being too aggressive. I answered this in my email below - I think it has to do with a misconception about CUBIC.

3) ABE only working in a corner case of very long RTTs:

This seems to me to be an exaggeration. Indeed, the benefits that we saw got more pronounced with larger RTTs. However, they didn't need to be huge: with CoDel, in our real-life tests we already saw a benefit with RTT values as low as 40 ms (see fig. 11 a in the tech. rep. ( http://heim.ifi.uio.no/michawe/research/publications/CAIA-TR-150710A.pdf ), which shows a throughput change from approximately 17 Mbps to very close to 20 Mbps across a 20 Mbps link). As figure 3 in the same tech.rep. shows, PIE maintains very good throughput up to an RTT of at least 80ms, but this does come at the cost of somewhat higher queuing delay. It's just the trade-off that one has to deal with when trying to keep the queue low yet get good utilization, and that trade-off is much worse with a TCP that uses a multiplication factor of 0.5 than when that factor is 0.8.

Cheers,
Michael

> Begin forwarded message:
> 
> From: Michael Welzl <[email-masked]>
> Subject: Re: [iccrg] Review of draft-khademi-alternativebackoff-ecn-01.txt
> Date: 22. november 2015 kl. 00.34.27 CET
> To: Bob Briscoe <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "Scharf, Michael \(Michael\)" <[email-masked]>, grenville armitage <[email-masked]>
> Resent-From: <[email-masked]>
> 
> Hi Bob,
> 
> I’ll try to answer in more detail soon - but here’s a general note:
> 
> I think I now finally understand that your major concern - the fact that we don’t talk much about how aggressive ABE is when the BDP is small - is due to a misunderstanding.
> 
> Our draft doesn’t go into a long discussion of the impact that ABE flows with a small BDP could have on other flows.
> I now understand that you think that ABE’s aggressive behavior with small BDPs is something unheard of (and would therefore have to be highlighted): flows that, in the presence of ECN feedback, would *always* multiply with 0.8 - while we only justify this by saying “CUBIC did the same”!   (“did” for 0.8, “does” for 0.7)
> 
> However, this:
> 
>> Similar 'unfairness' is rarely exhibited by Cubic, because Cubic falls back to Reno mode, at least for any BDP seen today over a realistic public access network (which typically restricts the path at one end at least). For instance, with a typical RTT of 20ms, TCP Cubic remains in Reno mode up to about 500Mb/s.
> 
> is wrong. Unless I totally misunderstood the code, graphs I've seen are wrong, and/or my memory plays tricks on me …. when it sees a loss or ECN mark, CUBIC *always* multiplies with its beta, which was 0.8 for a while and later became 0.7.
> 
> For the CUBIC=0.8 case (and 0.7 can be debated if we really must), ABE is therefore strictly only less aggressive than CUBIC (which has already been evaluated to death):
> - it increases exactly like Reno
> - it decreases like CUBIC, but only in response to an ECN mark, not loss
> 
> Cheers,
> Michael
> 
> _______________________________________________
> iccrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/iccrg