News for hackers. Stuff that matters.
Re:Low Latency, Low Loss, and Scalable Throughput (L4S) Inte... by callalex on Monday December 11, 2023 @11:50AM (#38602188)
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.
Re:Low Latency, Low Loss, and Scalable Throughput (L4S) Inte... by ajb on Monday December 11, 2023 @12:30PM (#38602581)
This 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.
Re:Low Latency, Low Loss, and Scalable Throughput (L4S) Inte... by thehappysellout on Monday December 11, 2023 @12:08PM (#38602344)
I 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.

Re:Low Latency, Low Loss, and Scalable Throughput (L4S) Inte... by asylteltine on Monday December 11, 2023 @11:51AM (#38602203)
You ever get that robotic latency thing? That’s because of udp and the stream allowing dropped packets at all. It’s a horrible experience.
Re:Low Latency, Low Loss, and Scalable Throughput (L4S) Inte... by cma on Monday December 11, 2023 @07:04PM (#38607264)
You can use udp and still do much better through things like adapting reed solomon or simple XOR error correction to packet loss statistics.