TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

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

371 点作者 monkburger超过 1 年前

19 条评论

toomim超过 1 年前
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 &quot;woah... I didn&#x27;t think this would ever be possible.&quot;<p>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!
评论 #38599873 未加载
评论 #38598851 未加载
评论 #38599684 未加载
hmottestad超过 1 年前
I was wondering how the receiver tells the sender that there was congestion. So I tried to figure it out, but it wasn&#x27;t the easiest to find.<p>Essentially the details are documented in <a href="https:&#x2F;&#x2F;www.rfc-editor.org&#x2F;info&#x2F;rfc3168" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.rfc-editor.org&#x2F;info&#x2F;rfc3168</a><p>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.<p>For more details, here is the relevant section:<p>* An ECT codepoint is set in packets transmitted by the sender to indicate that ECN is supported by the transport entities for these packets.<p>* 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.<p>* 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.<p>* The sender receives the TCP ACK with ECN-Echo set, and reacts to the congestion as if a packet had been dropped.<p>* 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.
barathr超过 1 年前
Bob Briscoe has been on this line of thought for a long time. I&#x27;d recommend reading a couple of his classics on the topic, including:<p><a href="http:&#x2F;&#x2F;www.sigcomm.org&#x2F;sites&#x2F;default&#x2F;files&#x2F;ccr&#x2F;papers&#x2F;2007&#x2F;April&#x2F;1232919-1232926.pdf" rel="nofollow noreferrer">http:&#x2F;&#x2F;www.sigcomm.org&#x2F;sites&#x2F;default&#x2F;files&#x2F;ccr&#x2F;papers&#x2F;2007&#x2F;A...</a><p><a href="https:&#x2F;&#x2F;dl.acm.org&#x2F;doi&#x2F;pdf&#x2F;10.1145&#x2F;1080091.1080124" rel="nofollow noreferrer">https:&#x2F;&#x2F;dl.acm.org&#x2F;doi&#x2F;pdf&#x2F;10.1145&#x2F;1080091.1080124</a>
评论 #38599018 未加载
vkdelta超过 1 年前
Some tests were done on Comcast networks on cable plant.<p>Slide deck below explains it:<p><a href="https:&#x2F;&#x2F;datatracker.ietf.org&#x2F;meeting&#x2F;118&#x2F;materials&#x2F;slides-118-tsvwg-sessa-61-l4s-experience-00" rel="nofollow noreferrer">https:&#x2F;&#x2F;datatracker.ietf.org&#x2F;meeting&#x2F;118&#x2F;materials&#x2F;slides-11...</a><p>Not sure where this leads but I guess ISPs will start charging toll for express lanes
评论 #38598184 未加载
评论 #38598245 未加载
评论 #38601209 未加载
cepholdapod超过 1 年前
If 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
评论 #38603882 未加载
danr4超过 1 年前
I just hope they pronounce it &quot;L-Force&quot;
评论 #38603940 未加载
virgildotcodes超过 1 年前
In case anyone else was curious, I found a brief demo of this in use with a video feed from an RC car: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=RZmS10djDEg" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=RZmS10djDEg</a>
评论 #38603693 未加载
muxamilian超过 1 年前
While it&#x27;s a step in the right direction, there&#x27;s a problem if there&#x27;s at least one &#x27;malicious&#x27; 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&#x27;s fair queuing, they can trust L4S to treat them fairly.<p>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 (<a href="https:&#x2F;&#x2F;github.com&#x2F;muxamilian&#x2F;fair-queuing-aware-congestion-control">https:&#x2F;&#x2F;github.com&#x2F;muxamilian&#x2F;fair-queuing-aware-congestion-...</a>).
评论 #38600139 未加载
dozaa超过 1 年前
What does this mean in practicality as a user? Will e.g. video calls be closer to real-time? There&#x27;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?
评论 #38605189 未加载
评论 #38601247 未加载
评论 #38602054 未加载
apienx超过 1 年前
Essentially, L4S shrinks the latency feedback loop. The second half of this video explains it quite nicely: <a href="https:&#x2F;&#x2F;youtu.be&#x2F;tAVwmUG21OY?si=lydbqfNL80Y8Uxvp" rel="nofollow noreferrer">https:&#x2F;&#x2F;youtu.be&#x2F;tAVwmUG21OY?si=lydbqfNL80Y8Uxvp</a>
评论 #38603950 未加载
tamarlikesdata超过 1 年前
How can you differentiate between L4S and non-L4S traffic at the network level, especially in mixed traffic environments?
评论 #38601257 未加载
评论 #38598745 未加载
ncruces超过 1 年前
How does it compare to μTP (Micro Transport Protocol)?<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Micro_Transport_Protocol" rel="nofollow noreferrer">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Micro_Transport_Protocol</a>
评论 #38598868 未加载
评论 #38601261 未加载
callalex超过 1 年前
Im 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.
评论 #38602344 未加载
评论 #38602581 未加载
评论 #38602203 未加载
ksjskskskkk超过 1 年前
a rfc which simply sells two others rfc... sigh<p>&gt; Center TCP (DCTCP) [RFC8257] and a Dual-Queue Coupled AQM [RFC9332]<p>this only exists to ask that cable modems (and maybe mobile phones?) use that too
sylware超过 1 年前
Like diffserv? Allowing to tell the ISP about low latency traffic?<p>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超过 1 年前
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....
评论 #38601700 未加载
eru超过 1 年前
How does this interact with eg BBR?
评论 #38599337 未加载
评论 #38599977 未加载
1123581321超过 1 年前
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?
评论 #38599058 未加载
评论 #38601281 未加载
Ostatnigrosh超过 1 年前
what in the Pied Piper?