Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: RFC 9330 • Hacker News Board

Re: Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: RFC 9330

#51

Post by the8472 » Mon, Dec 11, 2023, 12:22 PM UTC

eru wrote: post #42

How does this interact with eg BBR?

BBRv1 doesn't take ECN into account. BBRv2/v3 do, and it's mentioned in the RFC:

       Scalable variants are
       under consideration for more recent transport protocols (e.g.,
       QUIC), and the L4S ECN part of BBRv2 [BBRv2] [BBR-CC] is a
       Scalable congestion control intended for the TCP and QUIC
       transports, amongst others.

Re: Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: RFC 9330

#52

Post by muxamilian » Mon, Dec 11, 2023, 12:26 PM UTC

While it's a step in the right direction, there's a problem if there's at least one 'malicious' actor, who ignores the congestion feedback and just wants a larger share of bandwidth. Then all other actors will retreat and the unfair actors get what they want. Unfortunately it is hard to know for a good actor if the other actors are playing nicely or not. Only if a good actor knows that there's fair queuing, they can trust L4S to treat them fairly.

This can be solved by complementing L4S with fair queuing (e.g. fq_codel) and by making sure that congestion control can detect the presence of fair queuing (https://github.com/muxamilian/fair-queuing-aware-congestion-...).

Re: Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: RFC 9330

#53

Post by ajb » Mon, Dec 11, 2023, 12:44 PM UTC

muxamilian wrote: post #52

While it's a step in the right direction, there's a problem if there's at least one 'malicious' actor, who ignores the congestion feedback and just wants a larger share of bandwidth. Then all other actors will retreat and the unfair actors get what they want. Unfortunately it is hard to know for a good actor if the other actors are playing nicely or not. Only if a good actor knows that there's fair queuing, they can…

To clarify this - most ISPs implement per customer bandwidth allocation, so a malicious actor should not be able to take share from other customers.

The FQ thing is a part of a larger dispute. Without FQ is is already the case that, irrespective of L4S, fairness is implemented by end hosts, and an end host (eg a server) can ignore congestion responses and take more than a fair share. This is not an issue which L4S introduces, but some argue that L4S "makes it easier" to take a larger share.

The people behind FQ argue that the network should guarantee fair sharing, but not everyone believes they have chosen the right fairness metric. In particular one of the main proponents of L4S does not, as can be seen from his paper linked here: https://news.ycombinator.com/item?id=38598023

Re: Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: RFC 9330

#54

Post by xorcist » Mon, Dec 11, 2023, 1:09 PM UTC

fragmede wrote: post #36

ajb wrote: post #30

Earlier quoted context omitted.

That bit is already there. L4S changes the meaning of the bit to allow a more accurate signal.

More particularly, L4S is an advancement to the existing ECN (Explicit Congestion Notification) extension to TCP/IP, allowing for more advanced algorithms to cut down latency further.

The main problem with ECN was the remarkably widespread behaviour by middleboxes that either cleared that bit or straight up dropped the packets. Maybe that situation has improved now?

Re: Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: RFC 9330

#55

Post by sylware » Mon, Dec 11, 2023, 1:22 PM UTC

Like diffserv? Allowing to tell the ISP about low latency traffic?

Ofc, ISPs would have to aggressively limit this type of traffic as it would be abused otherwise (video game gameplay traffic, and voice call streams).

Re: Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: RFC 9330

#56

Post by jlivingood » Mon, Dec 11, 2023, 2:58 PM UTC

xorcist wrote: post #54

fragmede wrote: post #36

Earlier quoted context omitted.

More particularly, L4S is an advancement to the existing ECN (Explicit Congestion Notification) extension to TCP/IP, allowing for more advanced algorithms to cut down latency further.

The main problem with ECN was the remarkably widespread behaviour by middleboxes that either cleared that bit or straight up dropped the packets. Maybe that situation has improved now?

It has definitely changed. Looking at measurements on this it seems there is only 1 major transit network doing that, and they are working to fix it.

Re: Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: RFC 9330

#57

Post by jlivingood » Mon, Dec 11, 2023, 3:00 PM UTC

vkdelta wrote: post #4

Some tests were done on Comcast networks on cable plant. Slide deck below explains it: https://datatracker.ietf.org/meeting/118/materials/slides-11... Not sure where this leads but I guess ISPs will start charging toll for express lanes

> "Not sure where this leads but I guess ISPs will start charging toll for express lanes"

Doubtful IMO. I think latency becomes another competitive differentiator, much like throughput/speed is today. (this is a personal comment but I work at Comcast)

Re: Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: RFC 9330

#58

Post by jlivingood » Mon, Dec 11, 2023, 3:01 PM UTC

jesperwe wrote: post #5

vkdelta wrote: post #4

Some tests were done on Comcast networks on cable plant. Slide deck below explains it: https://datatracker.ietf.org/meeting/118/materials/slides-11... Not sure where this leads but I guess ISPs will start charging toll for express lanes

L4S is not really an express lane. It is a way for applications to know when their traffic is congested, enabling them to scale DOWN their traffic to alleviate the congestion. Less congestion means less latency.

100% agree - read my IETF Internet Draft for more on that. :-) https://www.ietf.org/archive/id/draft-livingood-low-latency-...

Re: Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: RFC 9330

#59

Post by jlivingood » Mon, Dec 11, 2023, 3:02 PM UTC

polonbike wrote: post #12

jesperwe wrote: post #5

Earlier quoted context omitted.

L4S is not really an express lane. It is a way for applications to know when their traffic is congested, enabling them to scale DOWN their traffic to alleviate the congestion. Less congestion means less latency.

I guess ISPs will start charging toll for congestionless lanes...

See my comment above - doubt this will happen - rather it will become a differentiator like thoughput.

Re: Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: RFC 9330

#60

Post by jlivingood » Mon, Dec 11, 2023, 3:04 PM UTC

dozaa wrote: post #43

What does this mean in practicality as a user? Will e.g. video calls be closer to real-time? There's usually about 0.5-1 second delay which leads to a lot of hiccups and interruptions when speaking with each other. What other application uses will be significantly improved?

It makes new cloud-based apps realistically & reliably workable - think cloud gaming and cloud AR. It also makes interactive stuff like gaming and video conferencing perform a lot better w/o lag. But really anything interactive (user & device) should be better given how many round trips it currently takes to paint a web page or stream video to handle an AI assistant (Alexa) interaction.