4 ms·
Interestingly, I've found TCP_Illinois[0] to do the best on lossy links. Case in point was a cable modem isp I used for about a year once. The upstream was rate
by esaym 6y ago
Interestingly, I've found TCP_Illinois[0] to do the best on lossy links. Case in point was a cable modem isp I used for about a year once. The upstream was rated at 10mbs, but it would bounce between 1-5mbs. Using a UDP test, I noticed about a 0.2-1% packetloss on upstream only. I tried all the tcp algos in linux. Illinois did the best. And by "best" I mean it would hold a steady speed between 8-9mbs while others would get quite jumpy at times (or just never go above 5mbs). I'm limiting upstream to 9mbs via fq-codel as well. I've always found it strange Illinois is never brought up anywhere. It even has tuneable parameters too.
[0]:https://en.wikipedia.org/wiki/TCP-Illinois https://en.wikipedia.org/wiki/TCP-Illinois
- kev009 6y agoIt's a hybrid meaning it may struggle in direct competition with pure loss based algorithms. CUBIC, the Linux default, is somewhat notorious in causing bloat issues but these things tend to play out like an arms race. BBR is another hybrid and has tons of heuristics and tuning to try and adapt to these arms race conditions.
- vardump 6y agoNot questioning your conclusion; out of curiosity, did you also measure latency? You could get very close to maximum possible just by massively delaying & coalescing ACKs. In other words nearing blind transmission without caring about packet loss at all. But latency could get pretty bad!
- ignoramous 6y agoI believe congestion control would be at the application-layer with QUIC, that is, is it left upto L7 protocols like HTTP/3 to implement their own congestion control and packet loss? For HTTP/3, then, would fq-codel + BBR work nicely for foreground traffic like voice or video over WebRTC and, say, LEDBAT for background traffic like HTTP downloads or, say, bit-torrent over WebRTC? (I realise congestion control is long from being solvable: https://news.ycombinator.com/item?id=17455276 https://news.ycombinator.com/item?id=17455276)
- esaym 6y agoNot really. Was just using max average upload speed at. Test was done on my laptop, my firewall uses fq-codel so max bufferbloat delay would be below 50ms in most cases.
- vardump 6y agoSorry, should have been more specific. I wasn't talking about latency bufferbloat induces in other streams. But extra latency in any stream with packet loss. I meant stream of the receiving party would effectively block on any lost packet. You can't read past what you don't have yet. Imagine a stream that consists of 10 packets, and for simplicity that each packet takes a second to send. (Real life scenario would be about several orders of magnitude more packets and similarly shorter packet transmission times.) You receive packets 1 and 3-10. Thus in one second the application can see data from packet 1. But application's read is going to block until you also receive packet 2. Reception of packet 2 can't happen until 8s is spent receiving packets 3-10 and additional 1s resending 2 (plus whatever it took to send the ACK). So data from packet 2 would be 9s late from receiving application's point of view. Bulk transfers would approach maximal possible transfer rate because sender lost no time waiting for ACKs, but this would be pretty bad for something like remote desktop or streaming video. No sane general purpose network stream protocol would implement this policy for obvious reasons. But you'd sure get high bandwidth for file transfers!