Re: [Bloat] Comcast & L4S

[Sebastian Moeller <moeller0@gmx.de>]

Hi Jonathan...

> On 1. Feb 2025, at 18:26, Jonathan Morton <chromatix99@gmail.com> wrote:
> 
>> On 1 Feb, 2025, at 7:06 pm, Sebastian Moeller <moeller0@gmx.de> wrote:
>> 
>>> As with NQB, Cake already does essentially what L4S requires, except for default-configured Codel being less than ideal as an AQM for producing congestion signals for a DCTCP-type response.  I have no intention of modifying Cake to *specifically* accommodate L4S in any way.  If their crap doesn't work properly in a standards-compliant environment, that's THEIR problem.
>> 
>> Now, as advocatus diabolical, the way CoDel works we have interval and/or target as configurable parameters and a trade-off between maintaining utilisation over the wider internet and keeping the signalling reactive for closer by flows, maybe we could teach cake to allow a second set of interval/(automatically calculated) target to optimise for local and non local traffic, and use a proper (configurable and maskable) DSCP/TOS to steer packets into this? Maybe CS7 would do to signal its intent for local delivery?
> 
> Codel's default 5ms target is already pretty tight,

I am more concerned about the 100ms interval (target is linked to that), waiting 100ms before engaging is not great if the true RTT is in the low single digits...


> about as tight as you can reasonably make it while still accommodating typical levels of link-level jitter.  

Not sure, in a LAN with proper back pressure I would guess lower than 5ms to be achievable. This does not need to go crazy low, so 1 ms would likely do well, with an interval of 10ms... or if 5 ms is truly a sweet spot, maybe decouple interval and target so these can be configured independently (in spite of the theory that recommends target to be 5-10% of interval).

> And COBALT does already find and maintain the appropriate marking rate for DCTCP when required - it just takes a little while to ramp up, so there is a noticeable hump in the delay curve during flow startup.  I don't see any low-hanging fruit there; Codel is simply not designed for that congestion response style.

Fair, and I am not after DCTCP style here (L4S would be) but simply allowing a parallel codel for a tighter target.


> DelTiC is a bit more flexible in this respect.  I don't however plan to add DelTiC to Cake.  Rather, I'm building a new qdisc that does some of the same things as Cake, but using more advanced technology and generally learning some object lessons from the experience.

Great! May I propose something for you to ponder, assuming DelTic will also include a traffic shaper? 
One thing great with cake is the built-in traffic shaper, making setting it up a breeze. However that shaper tends to be relatively CPU-hungry (as shapers tend to be) and at the same time once it runs itself out of CPU cycles tends to not honor its latency target as well HTB+fq_codel tend to do. IIRC with HTB+fq_codel if you are CPI limited latency stays low, throughput takes a hit, with cake it is more that latency increases (not atrociously, even in that mode having cake is IMHO better than no cake) while thropughput takes a smaller hit. Not sure that this is something that can be easily addressed, but IMHO I prefer HTB+fq_codels behaviour in that regards.


> 
> - Jonathan Morton