[Bloat] Comcast & L4S

[Sebastian Moeller]

> On 1. Feb 2025, at 01:49, Dave Taht via Bloat <bloat at lists.bufferbloat.net> wrote:
> 
> https://www.lightreading.com/cable-technology/comcast-wields-low-latency-as-broadband-differentiator


And... the press invariably gets it wrong:

"Notable is Comcast's use of the Internet Engineering Task Force's Low Latency Low Loss Scalable Throughput (L4S) standards, which are used to process and support latency-sensitive traffic. LLD, which is part of the Low Latency DOCSIS specs, works by separating small, delay-sensitive, non-queue-building traffic (such as key clicks for an online game) from the primary (and much heavier) queue-building traffic that, for example, might carry a video stream or a large file upload or download."


As far as I can tell what LLD does is put both ECT(1) and NQB marked traffic into the same and single L-queue of its conditional priority scheduler (cable labs terminology), so if a video stream uses ECT(1) (essentially cloud gaming sends video streams) LLD will NOT separating it from NQB-marked gaming traffic.

Regards
	Sebastian




> 
> 
> On Fri, Jan 31, 2025 at 4:40 PM David Collier-Brown via Bloat
> <bloat at lists.bufferbloat.net> wrote:
>> 
>> What Comcast/L4S is doing was once called, by a Polish colleague,
>> "Peeing in the soup, so it smells more like me."
>> 
>> --dave
>> 
>> On 1/31/25 18:57, Dave Taht via Bloat 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.
>>> 
>>> The L4S side being enabled will also result in some applications
>>> actually trying to use it for cloud gaming. 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.
>>> 
>>> Negatives include explicit marking and potential DOS vectors as often
>>> discussed.  I do feel that in order to keep up with the jonesies,
>>> 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. 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.
>>> 
>>> 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. ACCECN seems to be making some progress.
>>> This makes it really hard to fool with this stuff.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 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
>>> 
>>> 
>> --
>> David Collier-Brown,         | Always do right. This will gratify
>> System Programmer and Author | some people and astonish the rest
>> davecb at spamcop.net           |              -- Mark Twain
>> 
>> _______________________________________________
>> Bloat mailing list
>> Bloat at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
> 
> 
> 
> -- 
> Dave Täht CSO, LibreQos
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat