Live data from Hacker News

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

datatracker.ietf.org

41–50 of 91 posts

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

#41

I’m having trouble determining if my 3.1 cable modem supports the draft spec. Is there a way to tell based on serial number? Are there hardware limitations that would prevent older 3.1 modems from receiving a software update to enable support?

It is quite rare that a modem, or home router have support for draft specs. I'm sorry to disappoint you

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

#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?

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

#44

I’m having trouble determining if my 3.1 cable modem supports the draft spec. Is there a way to tell based on serial number? Are there hardware limitations that would prevent older 3.1 modems from receiving a software update to enable support?

It is quite rare that a modem, or home router have support for draft specs. I'm sorry to disappoint you

Thanks. I’ll be on fiber instead of Comcast by the time ISPs are actually deploying this, so I was just curious about my current hardware.

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

#48
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!

It took a bit of searching, but I assume this is it?

https://youtube.com/watch?t=4900&v=RWjbrXxpzVU

(1hr21m for anyone whom the time link doesn't work for)

EDIT: Never mind, that's their hackathon recap. Still searching, this is not an easy conf to find talks for!

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

#49
post #38

Earlier quoted context omitted.

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…

I'll need to read up on this, but one potential misuse of this is to just always/often set that bit on traffic you want to suppress.

Which feels much easier and much less heavy-handed than what you can to today. Which technically is a great thing but just wondering about misuse aspect.

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

#50
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!

Actually somewhat better, even: you can let it control the rate factor of your video encoder directly, getting perceptual fairness instead of simple naive bandwidth fairness.
Post reply on HN