3 ms·
This is wrong. BBR still does retransmission if packets do not arrive on time, and any retransmission in the inner TCP stack automatically becomes badput that w
by xfs 7y ago
This is wrong. BBR still does retransmission if packets do not arrive on time, and any retransmission in the inner TCP stack automatically becomes badput that wastes the outer TCP stack which is likely at the same time also doing retransmission for packet losses at lower layer.
TCP_NOTSENT_LOWAT is not a solution to this either. It is a solution for HTTP/2 to be more aware of the congestion state and prioritize traffic properly, which itself does not do retransmission. It makes the buffer smaller so congestion is reported to upper layer earlier but still much later than when the actual congestion happens, distorting the upper/inner TCP congestion control. Also, a 128KiB value is hardcoded here for this knob, effectively rendering it only useful for a bandwidth delay product of 5Mbps * 200ms RTT.
- apenwarr 7y agoI’ve noticed a pattern where crypto people don’t seem to understand the edge cases of tcp congestion control, so I agree that this workaround is suspicious. Of course, it’s better than no VPN if your UDP is blocked. I like sshuttle’s way better (but I’m biased). However, it’s not broken in the exact way you’re thinking. TCP_NOTSENT_LOWAT is diffent from TCP_LOWAT. The latter would imply a hardcoded bandwidth-delay product. The one they’re using is a margin on top of the bandwidth-delay product, which mostly just depends on a fast enough CPU. They’re using a surprisingly high value for it though.