Re: I don't get it
It's a fundamental problem of abstract layered protocols that they can be suboptimal in specific concrete cases.
OSI networking had 5 different choices of transport layer, partly for this reason and partly to stop the French complaining, but that's a separate issue... If you imagine an old-fashioned network with "reliable" serial datalinks (i.e. each hop has its own error/loss recovery), the network mostly takes care of packet loss for you (thought not entirely). In a more modern network, packets get lost all the time and the endpoints are almost entirely responsible for dealing with it - and that means end-to-end acknowledgements. But when do you send them? If you "know" the receiving end will respond to arriving data with some data of its own, you can hold off sending the ACK and roll it up with the data being sent in the opposite direction - that can be done by guesswork, but of course if you pass the responsibility up to the application layer it has a better chance of knowing the optimal timing.
A more specific issue for QUIC is that HTTP/2.0 multiplexes individual data streams onto one TCP connection - a lost packet stalls every stream awaiting retransmission, even if data for only a single stream failed to arrive. Now of course, there are multiplexed transport protocols that don't suffer from this problem, but they all suffer from abstract vs. concrete compromise in terms of their chattiness and responsiveness.
If you go for entirely textbook layering, there's quite a lot of state that needs to be kept too for each HTTP, TLS and transport connection, some of which disappears if you roll all the layers up together.
The purpose of QUIC is essentially to come up with a transport+application protocol that is specific to the HTTP/TLS use case (though it has wider applications) and hence can be better optimised for that purpose. I can remember a time when the IETF would have been up in arms about layer violations, but I suspect this one is likely here to stay.
Biting the hand that feeds IT
