> Rejecting a valid packet because the order got shuffled is wasteful, This is not what happens. The data isn't dropped as long as there are only a few reorder

> Rejecting a valid packet because the order got shuffled is wasteful, This is not what happens. The data isn't dropped as long as there are only a few reordered segments. And with SACK the receiver can also acknowledge them. It's just not provided to the application layer because something in-between is still missing. This adds some latency if you're multiplexing multiple things over a single stream but it's not a loss in throughput. > The stream model of TCP with head of the line blocking is conceptually easy but ultimately the wrong model for transmitting blobs of data. A problem of google's own creation. > The problem is exacerbated by TLS encryption. It requires six packets, or three round trip times, to establish a TLS over TCP connection. That is hundreds of milliseconds before a single byte of payload can be transferred. Arguably the problem got exacerbated by the NSA and user-hostile ISPs. If they didn't push the entire internet into a low-trust equilibrium we could stick to simple protocols instead of having to expend more resources and increase complexity to ultimately get to the same state of not-being-intercepted as we had been before. A better response to a red queen's race is to dethrone the queen, not to build better running shoes. But yes, yes... these sure are nice shoes.