Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

datatracker.ietf.org

Post reply on HN
Print view View original

31–40 of 91 posts

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

#31

Post by Dylan16807 »

mkmk3 wrote: post #29
viraptor wrote: post #18

Earlier quoted context omitted.

There's literally an abstract at the top of this document which provides a summary. If you want more, you can feed it into chatgpt (or many other services) yourself, same as everyone here. There's no reason to post a summary as an unsolicited comment.

I'm pretty sure we often see the abstract posted as a comment for a quick summary, and I don't see it downvoted as hard. Not everyone goes through the link. But sure, they could have just posted that instead of going through GPT. Doesn't really matter much imo.

If you use the abstract from the document, then you know multiple people attempted to make it accurate, rather than zero people.

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

#32

Post by ajb »

ncruces wrote: post #26

How does it compare to μTP (Micro Transport Protocol)? https://en.wikipedia.org/wiki/Micro_Transport_Protocol

It is independent of that. The L4S standards change the IP layer to provide a more accurate ECN congestion signal , any transport protocol can then take advantage of it. There are versions of TCP and QUIC that do so, in theory a version of uTP could be made to do so as well.

However, from a brief look, uTP is designed for background transfers for which latency is not important, so there is no particular need to do so.

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

#33

Post by fragmede »

ksjskskskkk wrote: post #25
tamarlikesdata wrote: post #20

How can you differentiate between L4S and non-L4S traffic at the network level, especially in mixed traffic environments?

you'd never guess: a new heater bit

it reuses an existing header bit, but yeah

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

#34

Post by toomim »

ajb wrote: post #30
toomim wrote: post #10

This thing is cool. I saw a live demo at IETF 118 in Prague last month. It totally eliminates buffer bloat, which makes it awesome for video chat. I saw the demo and was like "woah... I didn't think this would ever be possible." It requires an additional bit to be inserted into IP packets, to carry information about when buffers are full (I think?), but it actually works. It feels like living in the future!

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

Yes, thanks for the clarification. IIRC was explained to me as "we put the last unused bit in IP packets to use, and get this great feature from it."

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

#35

Post by fabrixxm »

ksjskskskkk wrote: post #25
tamarlikesdata wrote: post #20

How can you differentiate between L4S and non-L4S traffic at the network level, especially in mixed traffic environments?

you'd never guess: a new heater bit

so you know when things get hot...

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

#36

Post by fragmede »

ajb wrote: post #30
toomim wrote: post #10

This thing is cool. I saw a live demo at IETF 118 in Prague last month. It totally eliminates buffer bloat, which makes it awesome for video chat. I saw the demo and was like "woah... I didn't think this would ever be possible." It requires an additional bit to be inserted into IP packets, to carry information about when buffers are full (I think?), but it actually works. It feels like living in the future!

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.

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

#37

Post by ajb »

Phelinofist wrote: post #21
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.

How is that different to TCP congestion control?

TCP congestion control can use this new signal, if present. An update to the TCP protocol which allows it to do is going through IETF at present: https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ec...

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

#38

Post by toomim »

Phelinofist wrote: post #21
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.

How is that different to TCP congestion control?

TCP congestion control relies on packets being dropped to signal that a link is congested.

L4S actually includes an extra bit of information in IP packets that routers can mutate to explicitly say when they are congested.

This means that you (a) don't need to play exponential backoff games, (b), don't need to re-send redundant packets, and (c) don't need big buffers in routers.

You need big buffers in routers because otherwise exponential backoff goes crazy. But when you add big buffers, you get latency, which is another kind of suck.

In order to avoid latency, you need to avoid buffers, which is hard unless you avoid exponential backoff. To avoid exponential backoff, you need routers to actually communicate their congestion, by sending more information. L4S does that by using an unallocated bit in IP packets.

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

#39

Post by ajb »

toomim wrote: post #34
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.

Yes, thanks for the clarification. IIRC was explained to me as "we put the last unused bit in IP packets to use, and get this great feature from it."

Yeah. It being the last bit (really the last codepoint in a 2 bit field) there was a big argument over it:

https://datatracker.ietf.org/meeting/interim-2020-tsvwg-01/s...

https://mailarchive.ietf.org/arch/msg/tsvwg/rXWRHAyGOuu_qOGM...

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

#40

Post by monkburger »

barathr wrote: post #3

Bob Briscoe has been on this line of thought for a long time. I'd recommend reading a couple of his classics on the topic, including: http://www.sigcomm.org/sites/default/files/ccr/papers/2007/A... https://dl.acm.org/doi/pdf/10.1145/1080091.1080124

Thank you for the links. I will read over them.
Post reply on HN