Hi Jonathan
> On Dec 14, 2021, at 10:57, Jonathan Morton <chromati...@gmail.com> wrote:
>
>> On 14 Dec, 2021, at 8:06 am, Dave Taht <dave.t...@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
