3 ms·
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 o
by 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 agoWiFi generally doesn't drop packets - it's usual failure mode is for latency to spike horribly for a clump of packets.
- piannucci 8y agoUnder 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 agoIt'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 agoPacket loss is an essential part of TCP to determine max. throughput.
- jabl 8y agoNot with BBR.
- zamadatix 8y agoOtoh your connection is already doing pretty good if the main source of congestion is the wireless link.