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

61–70 of 91 posts

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

#61

Post by jlivingood »

tamarlikesdata wrote: post #20

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

I wrote a simplified summary of the IETF specs FWIW: https://github.com/jlivingood/IETF-L4S-Deployment/blob/main/...

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

#62

Post by jlivingood »

ncruces wrote: post #26

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

UTP is intended to be less than best effort priority. This is about all the apps trying to share queues at best effort (1 level up).

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

#63

Post by jlivingood »

1123581321 wrote: post #13

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?

Several D3.1 modems support it now but most will need to be updated. Many of the vendors have been testing at quarterly L4S interop events, so I would expect them all to have production grade s/w next year.

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

#65

Post by hmottestad »

ddalex wrote: post #64

How does the feedback loop works ? I.e. the routers need to tell the source (upstream) to back off , but this used an IP header bit, so there is No guaranteed Return Stream....

With TCP the receiver has to send an ACK back to the sender. If the receiver sees that the congestion bit is set on a packet it gets from the sender then it will set the same bit on the ACK packet it sends back to the sender to acknowledge that the packet was received. This ACK is sent anyways, since it's part of how the sliding window is designed with TCP.

There are built in ways for the TCP protocol to handle congestion, but it doesn't allow a router to signal congestion. The router just has to hope for the sender to detect the congestion fast enough.

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

#67

Post by 0xdeadbeefbabe »

tjoff wrote: post #49
toomim wrote: post #38

Earlier quoted context omitted.

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.

A router could pretend to drop packets too, but that would result in higher latency. With L4S can a router cheat and get lower latency?

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

#68

Post by [deleted] »

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?

[deleted]
Post reply on HN