5 ms·

Interesting comment under the post: >The problem is fairness in the presence of network congestion. To a large extent it depends on most TCP implementations us

Interesting comment under the post: >The problem is fairness in the presence of network congestion. To a large extent it depends on most TCP implementations using the same congestion control algorithm, or at least algorithms that have the same general behavior. Google's developed a new algorithm called BBR that is robust, but also unfair. When a TCP connection implementing the NewReno algorithm shares a congested link with another one implementing BBR, the BBR grabs the lion's share of the bandwidth: >https://ripe76.ripe.net/presentations/10-2018-05-15-bbr.pdf https://ripe76.ripe.net/presentations/10-2018-05-15-bbr.pdf >QUIC specifies NewReno as default and mentions CUBIC, but the choice of algorithm is left to the implementation. I can easily envision Google using BBR for connections between Chrome and Google properties, which means Google traffic would be prioritized over competitors'. Over time, more players would implement BBR in a race to the bottom (or a tragedy of the commons) and Internet brown-outs as in the 1980s and 1990s would come back. https://blog.erratasec.com/2018/11/some-notes-about-http3.html?showComment=1542664152300&m=1#c2719702969623179467 https://blog.erratasec.com/2018/11/some-notes-about-http3.ht...

piannucci 8y ago
Race to the bottom is one thing. Yes, so-called “TCP unfriendly” protocols will muscle out any protocol that reacts to probability p random packet drops by a one-over-root-p reduction in throughput. But that does NOT mean that BBR will fail to avoid congestive collapse. The one-over-root-p behavior is outdated and actually harmful on wireless links, anyway; it was designed for the assumption that all losses are congestive losses; but today, many losses are purely random and not an indicator of congestion. BBR and other modern TCP-unfriendly congestion control protocols are a necessary step. TCP-friendliness must die.
- richardwhiuk 8y ago
  WiFi generally doesn't drop packets - it's usual failure mode is for latency to spike horribly for a clump of packets.
  - piannucci 8y ago
    Under the hood, what's happening is that the physical layer is reporting that a packet failed to decode, and the link layer is attempting retransmission at a series of lower and lower fallback rates. It's designed this way because if it fails to deliver a packet, TCP will freak out. There's an RFC about the general case of designing link layers to hide random losses: https://tools.ietf.org/html/rfc3366 https://tools.ietf.org/html/rfc3366
    - zamadatix 8y ago
      It's not so much just because "tcp will freak out" as much as it is understanding no transport layer retransmission algorithms operating on the scale of 100+ms can be a replacement for 100us+ link layer reliability mechanisms like FEC and retransmission.
    - gsich 8y ago
      Packet loss is an essential part of TCP to determine max. throughput.
      - jabl 8y ago
        Not with BBR.
- zamadatix 8y ago
  Otoh your connection is already doing pretty good if the main source of congestion is the wireless link.
Dylan16807 8y ago
> and Internet brown-outs as in the 1980s and 1990s would come back. That part definitely needs more justification. An algorithm playing badly with NewReno doesn't mean that we'd be worse off if every system switched to it.
- ori_b 8y ago
  Eagerly waiting for you to start sending patches for every system, including proprietary and unmaintained ones, and ensuring that those get included by default.
  - netheril96 8y ago
    Why would he start sending patches for them? He already benefits from BBR himself. He doesn’t need to lift everyone else to enjoy the benefits, unlike the IPv4 to IPv6 transition.
    - ori_b 8y ago
      And I benefit from driving on the sidewalk, why should I have to care how my car interacts with those tcp-using pedestrians? If you break TCP, and your answer is that "we'd be ok if every system switched to it", then you'd better start working on switching every system.
      - Dylan16807 8y ago
        Well I was responding to a claim that it would ruin all traffic, including the people that switched. It's not my job to defend against an entirely different argument. And this kind of thing needs more numbers in general. Maybe in a large mix of traffic, outside the edge case of a saturated link with two streams, it doesn't dominate too badly. Maybe because TCP incorrectly blocks so often, the average 'victim' user still benefits overall because only some of their devices are unpatched.
        ori_b 8y ago
the8472 8y ago
AQM is smarter than it was in the nineties. At worst network admins will have to deploy cake with triple-isolate to ensure fairness between hosts. It is even part of the mainline kernel now.

piannucci 8y ago

Race to the bottom is one thing. Yes, so-called “TCP unfriendly” protocols will muscle out any protocol that reacts to probability p random packet drops by a one-over-root-p reduction in throughput. But that does NOT mean that BBR will fail to avoid congestive collapse. The one-over-root-p behavior is outdated and actually harmful on wireless links, anyway; it was designed for the assumption that all losses are congestive losses; but today, many losses are purely random and not an indicator of congestion. BBR and other modern TCP-unfriendly congestion control protocols are a necessary step. TCP-friendliness must die.

richardwhiuk 8y ago
WiFi generally doesn't drop packets - it's usual failure mode is for latency to spike horribly for a clump of packets.
- piannucci 8y ago
  Under the hood, what's happening is that the physical layer is reporting that a packet failed to decode, and the link layer is attempting retransmission at a series of lower and lower fallback rates. It's designed this way because if it fails to deliver a packet, TCP will freak out. There's an RFC about the general case of designing link layers to hide random losses: https://tools.ietf.org/html/rfc3366 https://tools.ietf.org/html/rfc3366
  - zamadatix 8y ago
    It's not so much just because "tcp will freak out" as much as it is understanding no transport layer retransmission algorithms operating on the scale of 100+ms can be a replacement for 100us+ link layer reliability mechanisms like FEC and retransmission.
  - gsich 8y ago
    Packet loss is an essential part of TCP to determine max. throughput.
    - jabl 8y ago
      Not with BBR.
zamadatix 8y ago
Otoh your connection is already doing pretty good if the main source of congestion is the wireless link.

Dylan16807 8y ago

> and Internet brown-outs as in the 1980s and 1990s would come back. That part definitely needs more justification. An algorithm playing badly with NewReno doesn't mean that we'd be worse off if every system switched to it.

ori_b 8y ago
Eagerly waiting for you to start sending patches for every system, including proprietary and unmaintained ones, and ensuring that those get included by default.
- netheril96 8y ago
  Why would he start sending patches for them? He already benefits from BBR himself. He doesn’t need to lift everyone else to enjoy the benefits, unlike the IPv4 to IPv6 transition.
  - ori_b 8y ago
    And I benefit from driving on the sidewalk, why should I have to care how my car interacts with those tcp-using pedestrians? If you break TCP, and your answer is that "we'd be ok if every system switched to it", then you'd better start working on switching every system.
    - Dylan16807 8y ago
      Well I was responding to a claim that it would ruin all traffic, including the people that switched. It's not my job to defend against an entirely different argument. And this kind of thing needs more numbers in general. Maybe in a large mix of traffic, outside the edge case of a saturated link with two streams, it doesn't dominate too badly. Maybe because TCP incorrectly blocks so often, the average 'victim' user still benefits overall because only some of their devices are unpatched.
      - ori_b 8y ago

the8472 8y ago

AQM is smarter than it was in the nineties. At worst network admins will have to deploy cake with triple-isolate to ensure fairness between hosts. It is even part of the mainline kernel now.