> On 4 Jun, 2016, at 04:01, Andrew McGregor <andrewmcgr at 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