> It does! All the TLS/handshake data is transferred in CRYPTO frames (https://tools.ietf.org/html/draft-ietf-quic-transport-30#sec https://tools.ietf.org/html/

> It does! All the TLS/handshake data is transferred in CRYPTO frames (https://tools.ietf.org/html/draft-ietf-quic-transport-30#sec https://tools.ietf.org/html/draft-ietf-quic-transport-30#sec...). CRYPTO frames are more or less the same as STREAM frames (https://tools.ietf.org/html/draft-ietf-quic-transport-30#sec https://tools.ietf.org/html/draft-ietf-quic-transport-30#sec...). They both represent an ordered reliable byte stream - just in different namespaces. OK fair enough. > The Quic implementation has now the opportunity to merge everything into a single Quic "packet", and even a single Quic "frame", and send everything together. If those things were on top of datagrams, it might need to send the whole datagram again? QUIC doesn't resend datagrams; QUIC itself just uses datagram ACKs for congestion control. But if it notifies the next higher layer about ACKs, that layer is free to coalesce on retry, just like normal streaming. > There are also other scenarios: E.g. the stream getting reset while transmission is in progress. If that happens none of those data chunks will ever have to be retransmitted. I feel like having an additional layer here will make this harder and less efficient. STREAM_RESET would be entirely internal to the streaming layer, right? Again, the datagram layer doesn't re-transmit so no need to worry about that.