4 ms·

They use Reno? I don't know what's their business, but hopefully it doesn't involve lossy links like mobile data, which often drop packets even when uncongested

They use Reno? I don't know what's their business, but hopefully it doesn't involve lossy links like mobile data, which often drop packets even when uncongested... Reno can work nicely for low packet loss links, though.

kev009 7y ago
Just pertinent to this article, take a look at the links to their QUIC implementation. The reason I bring this up is because it's pretty easy to make a simplified fast path TCP stack that doesn't have all the branch heavy code necessary to do what the Linux TCP stack does well. So this is like a Phoronix style "benchmark". An undergrad level of understanding of systems will net you that you can get equal performance in userspace or kernel space with sufficient holistic thinking and accounting of data movement. I would caution that very few people are qualified to do this in userspace though, which is paradoxical because you will find a lot more people showing up claiming they know how. So basically this isn't a competent test; it isn't the production grade QUIC from google, it's a toy and the result is complete nonsense.
- vardump 7y ago
  Yeah, looked at their code [0]. You're right. I'm no TCP (or even congestion control) expert, but I wouldn't have needed to test their code in real life to tell exponentially reducing send window on a lost packet is just not going work in real life in 2020. They should have at least tested their code with simulated jittery latencies and packet loss typical for modern 4G networks. I bet Linux TCP would have left their implementation in dust. Another thing that caught my eye was their assumption that MTU is same on return path... probably often true, but definitely wouldn't count on it! Huge respect for them for putting their necks out and releasing code! Maybe this is their intention as well, to gain understanding through criticism. Also, perhaps this was just their MVP? It would certainly explain weird choice for congestion control. [0]: https://github.com/h2o/quicly/blob/master/lib/cc-reno.c https://github.com/h2o/quicly/blob/master/lib/cc-reno.c
  - kev009 7y ago
    It's just marketing bullshit, I don't feel bad at all for offering damning criticism. Companies hire people to do this kind of stuff on purpose. Many unfortunate software trends of the last decade have been started by equally flimsy PR jobs.
esaym 7y 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 7y ago
  It'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 7y ago
  Not 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 7y ago
    I 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 7y ago

kev009 7y ago

Just pertinent to this article, take a look at the links to their QUIC implementation. The reason I bring this up is because it's pretty easy to make a simplified fast path TCP stack that doesn't have all the branch heavy code necessary to do what the Linux TCP stack does well. So this is like a Phoronix style "benchmark". An undergrad level of understanding of systems will net you that you can get equal performance in userspace or kernel space with sufficient holistic thinking and accounting of data movement. I would caution that very few people are qualified to do this in userspace though, which is paradoxical because you will find a lot more people showing up claiming they know how. So basically this isn't a competent test; it isn't the production grade QUIC from google, it's a toy and the result is complete nonsense.

vardump 7y ago
Yeah, looked at their code [0]. You're right. I'm no TCP (or even congestion control) expert, but I wouldn't have needed to test their code in real life to tell exponentially reducing send window on a lost packet is just not going work in real life in 2020. They should have at least tested their code with simulated jittery latencies and packet loss typical for modern 4G networks. I bet Linux TCP would have left their implementation in dust. Another thing that caught my eye was their assumption that MTU is same on return path... probably often true, but definitely wouldn't count on it! Huge respect for them for putting their necks out and releasing code! Maybe this is their intention as well, to gain understanding through criticism. Also, perhaps this was just their MVP? It would certainly explain weird choice for congestion control. [0]: https://github.com/h2o/quicly/blob/master/lib/cc-reno.c https://github.com/h2o/quicly/blob/master/lib/cc-reno.c
- kev009 7y ago
  It's just marketing bullshit, I don't feel bad at all for offering damning criticism. Companies hire people to do this kind of stuff on purpose. Many unfortunate software trends of the last decade have been started by equally flimsy PR jobs.

esaym 7y 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 7y ago
It'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 7y ago
Not 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 7y ago
  I 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 7y ago