> But what here makes QUIC think that those other requests have any hope where the first didn't? To me, this approach seems like you're just spamming the link w

> But what here makes QUIC think that those other requests have any hope where the first didn't? To me, this approach seems like you're just spamming the link with packets and hoping for the best; those packets could just end up dropped like the other ones were. What makes QUIC think this approach will have any benefit? (It could, perhaps, if the link is just going to drop one packet and we can get right back to sending. I'm not sure that still conveys any benefit over TCP. There are a lot of ways to lose just a single packet. One way is a router is overloaded and so it throws some packets away. Another is some brief interference on a wireless connection. I think the phrase "spamming the link" is incorrect. QUIC does flow control to determine how much data to send. Once it's decided that the link can take a certain amount of data, it will send it. So, say it sends packets 1, 2 and 3. But, let's say that packet one is lost but 2 and 3 get through. With QUIC, the receiver can potentially do something with packets 2 and 3 with TCP, the receiver couldn't. Regardless, QUIC will respond to the packet loss by updating its flow control information - I haven't read anything that suggestions that QUIC responds by "spamming the link". > This whole thing makes me think there are two problems here: there's the actual network connection between two endpoints, and what its state is, how lossy it is, its PMTU, how much data we should allow in-flight between those two endpoints, etc. But then there is also logical streams, such as HTTP request/response pairs. It almost seems like to me any data about the link, such as PMTU/lossiness/window, should be shared between all TCP connections, and the individual logical streams should be otherwise cheap/easy to make. You've basically described what QUIC is in this paragraph