> On 4 Jun, 2016, at 04:01, Andrew McGregor <andrewm...@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 _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
