4 ms·

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 simplif

by kev009 6y 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 6y 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 6y 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.

by kev009 6y ago

vardump 6y 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 6y 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.