[Bloat] Comcast & L4S

[Sebastian Moeller]

Hi Dave,


> On 1. Feb 2025, at 00:57, Dave Taht <dave.taht at gmail.com> wrote:
> 
> Here are the positives:
> 
> For the first time, a major ISP has deployed the PIE AQM on all
> traffic. Before now Comcast was only doing that on the upstream.
> That´s 99.99% of all current comcast traffic getting an AQM on it. WIN.

Yes, that might be the lasting positive of the L4$ experiment, but boy do I wish they had used a better AQM than their gimped version of PIE... (I seem to recall they ripped out the part of pie that introduced some burst tolerance)...

> 
> The L4S side being enabled will also result in some applications
> actually trying to use it for cloud gaming.

I own no stock of cloud gaming companies nor use their services so not sure whether that is something the whole internet has been waiting for.

> There is a partnership
> with valve,
> meta, and apple, that implies that we will perhaps see some VR and AR
> applications trying to use it. I look forward to a killer app.

I would not hold my breath though... AR/VR has a hard enough time with local applications to gain meaningful marketshare (partly due to being priicy and cumbersome I would guess) so I am not confident adding the whole remote latency sensitive computations challenge on top is going to help.

> Negatives include explicit marking and potential DOS vectors as often
> discussed.  

Even more subtle, the way the L-queue is sensitive to bursts, I bet I can construct attack traffic that disrupts the low latency/low jitter promises of L4S for well-bahaving traffic without sticking out like a sore thumb on any traffic monitoring... this thing is engineered based on the principle of hopes and prayers, and an absurd notion of "incentives" team L4S always fudged the way convenient for a given argument.

> I do feel that in order to keep up with the jonesies,

Mmmh, do we really need to do this before the #L4S experiment has run its course? After all my expectation is it will peter out with a fizzle.

> we will have to add optional l4s marking to CAKE, which should
> outperform pie (mark-head), I just wish I knew what the right
> level was - at 100Mbit it seemed at 2ms was best.

This needs to be configurable.... I would assume just like it already is in fq_codel.

> We also need to
> remove classic RFC3168 style marking and drop instead when the L4S bit
> is present - across the entire linux and BSD ecosystem.

IFF then like in fq_codel, where this is immensely configurable, let's not hardcode any special behaviour for ECT(1) at least not before we have solid evidence that this new ECT(1) response has staying power, no?

> 
> There was an abortive attempt last year to get dualpi, accecn, and
> prague into mainstream linux, but it stumbled over GSO handing, and
> has not been resubmitted.

I bet nobody really cares, all the shakers and movers of L4S development will shop their own SDKs anyway. But could you elaborate how they stumbled over GSO? I thought cake gives a decent blueprint of how to do this (make it configurable). 

> ACCECN seems to be making some progress.

I doubt that... my gut feeling is the reappropriate the ACE flags as ACK counter might have some legs, but the AccECN options I really see these as paper-ware mostly.

> This makes it really hard to fool with this stuff.

What kind of fooling do you have in mind? By virtue of L4S defaultiung to a single L-queue to disturb it, all an attacker needs to be able to is get traffic into that queue (or even just the coupled c-queue, the joy of coupling) to cause mischief.
 
Regards
	Sebastian

P.S.: I really wish the laudable effort in deploying L4S with the right things like organised plug-fests, staged monitoreds introduction and even the accompanying PR-efforts would have been coupled with a better engineered solution then it would feel less of a "making pigs fly" exercise...

> 
> 
> 
> 
> 
> 
> 
> 
> On Fri, Jan 31, 2025 at 5:27 AM Sebastian Moeller via Bloat
> <bloat at lists.bufferbloat.net> wrote:
>> 
>> Hi Rich,
>> 
>> 
>>> On 31. Jan 2025, at 14:20, Rich Brown via Bloat <bloat at lists.bufferbloat.net> wrote:
>>> 
>>> Google Alerts sent me this: https://www.webpronews.com/comcasts-latency-leap-a-game-changer-in-network-performance/
>>> 
>>> Key quote: "Compatibility and Ecosystem: For L4S to have a significant impact, it requires an ecosystem where both the network infrastructure and the end-user devices support the standard..."
>>> 
>>> Can anyone spell "boil the ocean"? :-)
>>> 
>>> Or am I missing someting?
>> 
>> Well, the whole safety mechanisms in L4$ are laughably inadequate... this "design" essentially exposes a priority scheduler* without meaningful admission control to the open internet. This is so optimistically naive that it almost is funny again. I wish all the effort and hard work to make L4$ happen, would have been put in a reasonable design... but at least I learned one of the IETF's failure modes, and that is at least something valuable ;)
>> 
>> 
>> *) Just because something is not a strict preempting priority scheduler does not make it a good idea to expose it blindly... a conditional priority scheduler with e.g. L4$'  weight share of 10:1 already can do a lot of harm.
>> 
>> 
>>> 
>>> 
>>> _______________________________________________
>>> Bloat mailing list
>>> Bloat at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/bloat
>> 
>> _______________________________________________
>> Bloat mailing list
>> Bloat at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
> 
> 
> 
> -- 
> Dave Täht CSO, LibreQos