4 ms·

There's some efficiency gains from having streams at a lower level. E.g. if it's known that a transmission of a particular chunk of a stream failed, the next tr

There's some efficiency gains from having streams at a lower level. E.g. if it's known that a transmission of a particular chunk of a stream failed, the next transmission can capture that chunks plus additional data from that stream instead of just blindly retransmitting a full datagram. Besides that the crypto and handshake parts also need streams with guaranteed delivery and ordering, since they carry TLS stream data.

Ericson2314 6y ago
> E.g. if it's known that a transmission of a particular chunk of a stream failed, the next transmission can capture that chunks plus additional data from that stream instead of just blindly retransmitting a full datagram. But QUIC Datagrams do have ACKs, and don't have retries. Maybe we don't want them to have ACKs, but as long as it's opt-in, is that not enough for the upper layers? > Besides that the crypto and handshake parts also need streams with guaranteed delivery and ordering, since they carry TLS stream data. QUIC packets are individually encrypted so more metadata can be encrypted too. And I don't think connection establishment uses any sort of stream abstraction either since people speak of n-packet handshakes?
- Matthias247 6y ago
  > But QUIC Datagrams do have ACKs, and don't have retries. Maybe we don't want them to have ACKs, but as long as it's opt-in, is that not enough for the upper layers? Imagine the following: The users writes a few bytes on a stream, those get immediately transmitted and lost. Before the retransmission, the user enqueues more data. 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? 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. > And I don't think connection establishment uses any sort of stream abstraction either since people speak of n-packet handshakes? It does! All the TLS/handshake data is transferred in CRYPTO frames (https://tools.ietf.org/html/draft-ietf-quic-transport-30#section-19.6 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#section-19.8 https://tools.ietf.org/html/draft-ietf-quic-transport-30#sec...). They both represent an ordered reliable byte stream - just in different namespaces. This is important for the handshake, since the TLS implementation will act on this ordered stream data and kind of treat it as a TLS data over TCP stream.
  - Ericson2314 6y ago
    > 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.

Ericson2314 6y ago

> E.g. if it's known that a transmission of a particular chunk of a stream failed, the next transmission can capture that chunks plus additional data from that stream instead of just blindly retransmitting a full datagram. But QUIC Datagrams do have ACKs, and don't have retries. Maybe we don't want them to have ACKs, but as long as it's opt-in, is that not enough for the upper layers? > Besides that the crypto and handshake parts also need streams with guaranteed delivery and ordering, since they carry TLS stream data. QUIC packets are individually encrypted so more metadata can be encrypted too. And I don't think connection establishment uses any sort of stream abstraction either since people speak of n-packet handshakes?

Matthias247 6y ago
> But QUIC Datagrams do have ACKs, and don't have retries. Maybe we don't want them to have ACKs, but as long as it's opt-in, is that not enough for the upper layers? Imagine the following: The users writes a few bytes on a stream, those get immediately transmitted and lost. Before the retransmission, the user enqueues more data. 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? 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. > And I don't think connection establishment uses any sort of stream abstraction either since people speak of n-packet handshakes? It does! All the TLS/handshake data is transferred in CRYPTO frames (https://tools.ietf.org/html/draft-ietf-quic-transport-30#section-19.6 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#section-19.8 https://tools.ietf.org/html/draft-ietf-quic-transport-30#sec...). They both represent an ordered reliable byte stream - just in different namespaces. This is important for the handshake, since the TLS implementation will act on this ordered stream data and kind of treat it as a TLS data over TCP stream.
- Ericson2314 6y ago
  > 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.