4 ms·

I wish the QUIC design was datagram-first... so many client/server implementations don't implement the datagram extension properly because it's... well an exten

I wish the QUIC design was datagram-first... so many client/server implementations don't implement the datagram extension properly because it's... well an extension, and for most applications, reliable sequencing should be eschewed in favor of client-side reassembly. IMO QUIC was far too influenced by the legacy of how HTTP works when there was an opportunity to leapfrog a generation of bad decisions.

rofrol 5y ago
Can you elaborate more? Is there some more information about this datagram-first?
xanathar 5y ago
> so many client/server implementations don't implement the datagram extension properly I'm genuinely interested in what aspects you think are (or were) not implemented properly. I wrote most of the implementation of quiche's datagram extension and, well, if there's something that can be improved, I'm all for it. (aside: I think the standard should've considered an option for datagrams to opt-out of congestion control, given that most applications which want to take control over datagram sending probably also want to take control of available bandwidth and control congestion differently - e.g. by dropping encoding bitrate instead of queuing - but it is what it is).
- ninepoints 5y ago
  TBH I haven't looked at the quiche implementation specifically (not being as familiar with rust) so I should check that out. The main issue I saw with other implementations were mainly of the performance/optimization variety. The "blessed path" were definitely connection streams and I was seeing throughput drops when experimenting with datagrams.
ldng 5y ago
Very much like HTTP 2/3, it solves primarily Google's problems.
- Mauricebranagh 5y ago
  Users problems loading all those bloated JavaScript heavy sites
Matthias247 5y ago
> IMO QUIC was far too influenced by the legacy of how HTTP works when there was an opportunity to leapfrog a generation of bad decisions. I don't think this is fair. IETF QUIC doesn't have any references to HTTP anymore. It mostly provides bidirectional flow-controlled data streams - just like TCP. From an application point of view QUIC is pretty much TCP with the ability to have multiple concurrent streams after the connection was established. And reliable streams empower most higher layer networking protocols - not just HTTP. Implementing reliable flow controlled streams is not an easy task, therefore I think it was the right call to standardize this. Regarding the datagram extension: It's very easy to implement cocmpared to streams. If you have a need for it, consider contributing it to the QUIC implementation of your choice. For the datagram extension: If you have

rofrol 5y ago

Can you elaborate more? Is there some more information about this datagram-first?

xanathar 5y ago

> so many client/server implementations don't implement the datagram extension properly I'm genuinely interested in what aspects you think are (or were) not implemented properly. I wrote most of the implementation of quiche's datagram extension and, well, if there's something that can be improved, I'm all for it. (aside: I think the standard should've considered an option for datagrams to opt-out of congestion control, given that most applications which want to take control over datagram sending probably also want to take control of available bandwidth and control congestion differently - e.g. by dropping encoding bitrate instead of queuing - but it is what it is).

ninepoints 5y ago
TBH I haven't looked at the quiche implementation specifically (not being as familiar with rust) so I should check that out. The main issue I saw with other implementations were mainly of the performance/optimization variety. The "blessed path" were definitely connection streams and I was seeing throughput drops when experimenting with datagrams.

ldng 5y ago

Very much like HTTP 2/3, it solves primarily Google's problems.

Mauricebranagh 5y ago
Users problems loading all those bloated JavaScript heavy sites

Matthias247 5y ago

> IMO QUIC was far too influenced by the legacy of how HTTP works when there was an opportunity to leapfrog a generation of bad decisions. I don't think this is fair. IETF QUIC doesn't have any references to HTTP anymore. It mostly provides bidirectional flow-controlled data streams - just like TCP. From an application point of view QUIC is pretty much TCP with the ability to have multiple concurrent streams after the connection was established. And reliable streams empower most higher layer networking protocols - not just HTTP. Implementing reliable flow controlled streams is not an easy task, therefore I think it was the right call to standardize this. Regarding the datagram extension: It's very easy to implement cocmpared to streams. If you have a need for it, consider contributing it to the QUIC implementation of your choice. For the datagram extension: If you have