71–80 of 91 posts
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.
Earlier quoted context omitted.
L4S 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.
I guess ISPs will start charging toll for congestionless lanes...
Essentially the details are documented in 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.
While 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…
To 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 in…
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.
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.
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.
Earlier quoted context omitted.
To 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 in…
> 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 _…
I guess you are right that buffer bloat problems could pressure ISPs to avoid overprovisioning, and any solution to bufferbloat could take the pressure off. But you can also get bufferbloat and other latency issues without overprovisioning, so it doesn't seem to me to be a good reason to hold off implementing solutions to them.
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.
While 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…
To 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 in…
Earlier quoted context omitted.
To 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 in…
Where do they implement this?
Earlier quoted context omitted.
How is that different to TCP congestion control?
TCP congestion control can use this new signal, if present. An update to the TCP protocol which allows it to do is going through IETF at present: https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ec...