Re: [tcpm] About CUBIC and buffer draining

Sigh, copy + paste error fix, sorry - in line:

> On Mar 29, 2017, at 4:33 PM, Michael Welzl <michawe@ifi.uio.no> wrote:
> 
> Hi,
> 
> In Praveen’s very interesting presentation on TCP in Windows, today:
> https://www.ietf.org/proceedings/98/slides/slides-98-tcpm-tcp-improvements-in-windows-01.pdf
> he stated that “CUBIC builds up large buffer in absence of AQM”  (slide 4).
> 
> In the absence of an AQM algorithm, even a single Reno flow alone will not let a queue drain when it’s (for several practical reasons, slightly more than) a BDP in length. To allow a BDP worth of queuing to drain, the sender needs a backoff factor of 0.5 or less. CUBIC’s backoff (multiplication) factor is 0.7, so it can even produce a standing queue when the queue is smaller than a BDP.
> 
> For reasonably configured networks, and with background load fluctuations, that’s maybe not such a huge problem (after all, the Internet still works  ;-)  ).
> However, CUBIC’s backoff factor choice is “blind” - CUBIC has no idea of the length of the queue.
> 
> That’s what we’re trying to fix with ABE (draft-khademi-tcpm-alternativebackoff-ecn):

That should be: draft-ietf-tcpm-alternativebackoff-ecn-00

Cheers,
Michael

> because ECN is a hint that the queue was probably small, we can use a larger backoff factor (i.e. reduce by less).  => if the whole Internet would support ECN, and ABE was implemented as a way to back off, I would wonder: should CUBIC use 0.5 when it reacts to loss?
> 
> These are researchy futuristic musings. Getting back down to earth, I think it may be good to add a sentence to the CUBIC draft, where the backoff factor of 0.7 is introduced (last paragraph of section 3). There, the text now only says:
> 
> ***
>   CUBIC sets the multiplicative window decrease factor to 0.7 while
>   Standard TCP uses 0.5.  While this improves the scalability of the
>   protocol, a side effect of this decision is slower convergence
>   especially under low statistical multiplexing environments.
> ***
> 
> … but I think the fact that it is more likely to produce a standing queue is a bigger issue, and worth mentioning here.
> 
> Cheers,
> Michael
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm