Re: [Cake] [Codel] Proposing COBALT

[Jonathan Morton <chromatix99@gmail.com>]

> On 4 Jun, 2016, at 04:01, Andrew McGregor <andrewmcgr@gmail.com> wrote:
> 
> There are undoubtedly DCTCP-like ECN responses widely deployed, since
> that is the default behaviour in Windows Server (gated on RTT in some
> versions).  But also, ECN bleaching exists, as do servers with ECN
> response turned off even though they negotiate ECN.  It would be good
> to know some specifics as to which site, whose DC they're hosted in,
> etc.

I’m keeping my mouth shut until I’ve analysed the specific traffic in more detail, so I know what I’m accusing people of and precisely who to accuse.  It’s even possible that the fault lies in my ISP’s network - I think they’ve made some significant changes recently.

If people are really negotiating ECN and then ignoring its signals at the host level, that’s a clear RFC violation.  Fortunately, I think this particular site would be interested in correcting such behaviour if confirmed and explained.

> Also, do you have fallback behaviour such that an ECN-unresponsive
> flow eventually sees drops?  I think that will be essential.

Yes, COBALT essentially *is* such a mechanism.  The Codel half always uses ECN if it’s available (and drops otherwise), but the BLUE half - the part responsible for handling unresponsive flows in the first place - always uses packet drops.

Cake also performs “head drop on the longest queue” when the global queue limit is reached (as does fq_codel).  This can be considered a second such mechanism, though a much blunter one; it is significantly superior to tail-drop for two major reasons, but can easily result in burst loss.

It is also this overflow which acts as the up-trigger for BLUE; the longest queue not only gets the instant head-drop but a notification to its COBALT instance.

 - Jonathan Morton