[tcpm] About CUBIC and buffer draining

[Michael Welzl <[e-mail]>]

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): 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