[Cake] sometimes I worry about cobalt's effectiveness

[Sebastian Moeller]

Hi Jonathan

> On Dec 14, 2021, at 10:57, Jonathan Morton <chromatix99 at gmail.com> wrote:
> 
>> On 14 Dec, 2021, at 8:06 am, Dave Taht <dave.taht at gmail.com> wrote:
>> 
>> ok, it looks like ecn and perhaps dscp is busted on this mikrotik
>> release. Ton more plots, false starts, and packet captures here.
>> 
>> https://forum.mikrotik.com/viewtopic.php?p=897892#p897892
>> 
>> Also well, codel is doing better than cobalt, and SFQ at least at
>> these RTTs is doing really, really well.
> 
> Codel *with ECN disabled* is doing better under these conditions, based on what I can see via the Google Drive links.  This makes some sense if the ECN CE marks are being silently erased (which is *very* bad behaviour), rather than the packets carrying them being treated as dropped (as I'd expect from a wrong checksum).
> 
> Under this particular pathology, COBALT is still able to act via the BLUE algorithm, but in Cake this kicks in only when the queue first reads as full.  In other implementations of COBALT, it also triggers when the sojourn time reaches 400ms (by default).
> 
> Mikrotik - or whoever is responsible for this - needs to fix their crap so that the ECN field is processed correctly.  End of discussion.

Could we maybe introduce a no-ecn keyword to switch cake to drop only mode? If only to help diagnose ECN issues?

Regards
	Sebastian


> 
> - Jonathan Morton
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake