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 tel

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