Subject: [tcpm] About CUBIC and buffer draining

From: Michael Welzl <[email-masked]>
Date: Wed, 29 Mar 2017 16:33:27 -0500

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

---

From: Michael Welzl <[email-masked]>
Date: Thu, 30 Mar 2017 04:59:35 -0500

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

> On Mar 29, 2017, at 4:33 PM, Michael Welzl <[email-masked]> wrote:
> 
> Hi,
> 
> 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?
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm