8 ms·
Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: RFC 9330
- c54 3y ago[flagged]
- MrBuddyCasino 3y agoI found this useful and don’t understand the downvotes.
- Pixie_Dust 3y ago> I found this useful and don’t understand the downvotes. It's easier to downvote than post a refutation /s
- pocketarc 3y agoI would assume the downvotes are because the comment is GPT-generated. People come here for the community's comments and insights, not for GPT's summarisations, even if you yourself find them useful. I personally agree with the downvotes - I don't want to see every HN post littered with "this is what GPT-4 has to say about this".
- Villodre 3y agoAn excellent answer - the very same kind of post I come here to read and not the very same machine-generated content that's everywhere in the Net ;-)
- MrBuddyCasino 3y agoI think an AI summary, clearly marked as such, can be just as useful as the obligatory Archive link. I understand the aversion against „AI spam“, but I find it weird that a supposed tech community rejects AI tech wholesale.
- valvar 3y agoNothing's stopping users who want an AI summary from feeding the content into their favourite GPT. But it's not contributing anything meaningful to a HN discussion.
- viraptor 3y agoThe archive link is useful, because it provides you a way to access the page itself. Nobody here has subscriptions to every single service, so if there's something paywalled, that link is useful to almost everyone person. (And I wish HN did it automatically) A lazy gpt summary is not that.
- Closi 3y agoAgree - possibly this is even an example of how to do it? Clearly labelled as LLM generated and used to summarise a long RFC (where I personally didn’t find the abstract as clear as GPTs summary). But everyone will have their own views on this. There is definitely a lot of anti-AI or anti-LLM scepticism or denial on HN.
- rwiggins 3y agoIMO, an LLM-generated summary is almost never a useful post without further comment. I don't trust current LLMs to correctly summarize complicated and nuanced text. Now, if someone with the relevant expertise wanted to carefully read an article, feed it into an LLM for a summary, verify its correctness, and post that, I'd be alright with it. Or if the summary is interesting in some other way - like is it super wrong? or does it make interesting leaps? or maybe it is startlingly correct? - then sure, share it, but also share why it's interesting.
- viraptor 3y agoThere'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.
- mkmk3 3y agoI'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.
- Dylan16807 3y agoIf you use the abstract from the document, then you know multiple people attempted to make it accurate, rather than zero people.
- barathr 3y agoBob 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/April/1232919-1232926.pdf http://www.sigcomm.org/sites/default/files/ccr/papers/2007/A... https://dl.acm.org/doi/pdf/10.1145/1080091.1080124 https://dl.acm.org/doi/pdf/10.1145/1080091.1080124
- monkburger 3y agoThank you for the links. I will read over them.
- vkdelta 3y agoSome tests were done on Comcast networks on cable plant. Slide deck below explains it: https://datatracker.ietf.org/meeting/118/materials/slides-118-tsvwg-sessa-61-l4s-experience-00 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
- jesperwe 3y agoL4S 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.
- polonbike 3y agoI guess ISPs will start charging toll for congestionless lanes...
- jlivingood 3y agoSee my comment above - doubt this will happen - rather it will become a differentiator like thoughput.
- kmeisthax 3y agoThey already did that, L4S or no. "Fast lanes" usually come in the form of peering links or colocated cache servers, both of which involve actual new capacity. Prioritizing individual flows of traffic over ordinary transit links based on monetary value is something IP is uniquely ill-suited to do.
- Phelinofist 3y agoHow is that different to TCP congestion control?
- flumpcakes 3y agoCongestion control with TCP will eventually still need to send the same number of bytes down a pipe, albeit with added latency. After a while an application could notice and make a change, but it would be long enough for a user to notice poor service.
- toomim 3y agoThis 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!
- ajb 3y agoThat bit is already there. L4S changes the meaning of the bit to allow a more accurate signal.
- toomim 3y agoYes, 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."
- ajb 3y agoYeah. 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/session/tsvwg https://datatracker.ietf.org/meeting/interim-2020-tsvwg-01/s... https://mailarchive.ietf.org/arch/msg/tsvwg/rXWRHAyGOuu_qOGM3JkpK9whdS4/ https://mailarchive.ietf.org/arch/msg/tsvwg/rXWRHAyGOuu_qOGM...
- fragmede 3y agoMore 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.
- xorcist 3y agoThe 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?
- 1123581321 3y agoI’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?
- evilmonkey19 3y agoIt is quite rare that a modem, or home router have support for draft specs. I'm sorry to disappoint you
- 1123581321 3y agoThanks. 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.
- jlivingood 3y agoSeveral 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.
- danr4 3y agoI just hope they pronounce it "L-Force"
- ElijahLynn 3y agoI think that could catch on!
- signa11 3y ago‘force’ and ‘farce’ are just a hamming distance away.
- tamarlikesdata 3y agoHow can you differentiate between L4S and non-L4S traffic at the network level, especially in mixed traffic environments?
- ksjskskskkk 3y agoyou'd never guess: a new heater bit
- jlivingood 3y agoI wrote a simplified summary of the IETF specs FWIW: https://github.com/jlivingood/IETF-L4S-Deployment/blob/main/Network-Config-Guide.md https://github.com/jlivingood/IETF-L4S-Deployment/blob/main/...
- cepholdapod 3y agoIf you are interesting in learning more on L4S, there is a webinar series starting today on understandinglatency.com. Some of the authors of L4S, the head of Comcasts L4S field trail and some critical voices are speaking
- ElijahLynn 3y agoFixed link https://www.understandinglatency.com/ https://www.understandinglatency.com/ to be clickable.
- ncruces 3y agoHow does it compare to μTP (Micro Transport Protocol)? https://en.wikipedia.org/wiki/Micro_Transport_Protocol https://en.wikipedia.org/wiki/Micro_Transport_Protocol
- ajb 3y agoIt 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.
- jlivingood 3y agoUTP 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).
- ksjskskskkk 3y agoa rfc which simply sells two others rfc... sigh > Center TCP (DCTCP) [RFC8257] and a Dual-Queue Coupled AQM [RFC9332] this only exists to ask that cable modems (and maybe mobile phones?) use that too
- eru 3y agoHow does this interact with eg BBR?
- ajb 3y agoBBR is a congestion control algorithm, L4S provides a congestion control signal. So BBR can be updated to take advantage the L4S signal. Apparently there are some plans to do so.
- the8472 3y agoBBRv1 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.
- eru 3y agoThanks. I saw that mention in the article, but couldn't really make much of it.
- dozaa 3y agoWhat 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?
- jlivingood 3y agoIt 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.
- deleted 3y ago[deleted]
- supertrope 3y agoThis only resolves one source of delay in one ISP's network. Internet video chat is a mess because it's "best effort" at every level. The need for <3 Mbps bitrates means tough trade offs between quality, bitrate, CPU time, and latency. Bitrate is the hardest constraint. Commodity laptops have slower CPUs or if they have 6 core CPUs they keep them clocked down when on battery. Hardware accelerated video encoding is not universal. So quality and latency are sacrificed. Wi-Fi adds latency, especially when a laptop is on battery To deal with NAT many video chat services relay through cloud servers adding latency. https://hpbn.co/wifi/#measuring-and-optimizing-wifi-performance https://hpbn.co/wifi/#measuring-and-optimizing-wifi-performa...
- CardiB 3y ago[flagged]
- apienx 3y agoEssentially, L4S shrinks the latency feedback loop. The second half of this video explains it quite nicely: https://youtu.be/tAVwmUG21OY?si=lydbqfNL80Y8Uxvp https://youtu.be/tAVwmUG21OY?si=lydbqfNL80Y8Uxvp
- ElijahLynn 3y agoWhat timestamp would one start at?
- muxamilian 3y agoWhile 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-control https://github.com/muxamilian/fair-queuing-aware-congestion-...).
- ajb 3y agoTo 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 https://news.ycombinator.com/item?id=38598023
- qmarchi 3y ago> most ISPs implement per customer bandwidth allocation This really should have an asterisk (*). There is generally a limit on what an ISP will advertise, and what they will provide (usually ~110% of advertised). However, it's also extremely common that they overprovision segments on their network. In the case of a Coax network like Comcast, or Spectrum, they will overprovision the actual last-mile capacity so that _most_ times of the day, you'll receive your ~110% of advertised speeds, but during peak (mid-evening), it's extremely unlikely that you're going to receive even your advertised speeds, usually only ~70%. In the case for L4S, it would absolutely help "perceptively" resolve these kinds of congestion points, but the "evil take" would be that ISPs can extend their network upgrades further.
- sylware 3y agoLike 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).
- ddalex 3y agoHow 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....
- hmottestad 3y agoWith 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.
- virgildotcodes 3y agoIn case anyone else was curious, I found a brief demo of this in use with a video feed from an RC car: https://www.youtube.com/watch?v=RZmS10djDEg https://www.youtube.com/watch?v=RZmS10djDEg
- smusamashah 3y agoFound another looking up L4S https://www.youtube.com/watch?v=l6WSMU71Ub8 https://www.youtube.com/watch?v=l6WSMU71Ub8
- Ostatnigrosh 3y agowhat in the Pied Piper?
- callalex 3y agoIm confused, everyone here is talking about improvements to video conferencing and streaming, but those applications use UDP instead of TCP so I don’t understand how this will change anything.
- asylteltine 3y agoYou ever get that robotic latency thing? That’s because of udp and the stream allowing dropped packets at all. It’s a horrible experience.
- cma 3y agoYou can use udp and still do much better through things like adapting reed solomon or simple XOR error correction to packet loss statistics.
- thehappysellout 3y agoI think the key point is the bottleneck link is a shared resource. Many TCP flows traversing the link will drive it to a relatively high queue occupancy which causes higher delay for all traffic regardless of protocol. Only skimmed the proposal but looks like it isolates traffic using the new protocol by giving it a dedicated buffer, and the explicit congestion notification protocol would then keep the size of this queue much smaller at steady state when the link is saturated.
- ajb 3y agoThis standard is a change to IP, which TCP and UDP (and transports implemented on top of UDP) are both implemented on. So it applies to all of them. Each transport has to implement its own way of using it.
- hmottestad 3y agoI was wondering how the receiver tells the sender that there was congestion. So I tried to figure it out, but it wasn't the easiest to find. Essentially the details are documented in https://www.rfc-editor.org/info/rfc3168 https://www.rfc-editor.org/info/rfc3168 The simple answer is that there are more than just one flag. From what i gather there are three flags. One flag that the sender sets to inform the routers that it can handle ECN. A second flag is used by the router to tell the recipient that the router was congested. And a third flag is set in by the recipient when it sends an ACK package back to the sender. For more details, here is the relevant section: * An ECT codepoint is set in packets transmitted by the sender to indicate that ECN is supported by the transport entities for these packets. * An ECN-capable router detects impending congestion and detects that an ECT codepoint is set in the packet it is about to drop. Instead of dropping the packet, the router chooses to set the CE codepoint in the IP header and forwards the packet. * The receiver receives the packet with the CE codepoint set, and sets the ECN-Echo flag in its next TCP ACK sent to the sender. * The sender receives the TCP ACK with ECN-Echo set, and reacts to the congestion as if a packet had been dropped. * The sender sets the CWR flag in the TCP header of the next packet sent to the receiver to acknowledge its receipt of and reaction to the ECN-Echo flag.
- deleted 3y ago[deleted]