Hacker News new | past | comments | ask | show | jobs | submit login

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.



> 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).


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.


> 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


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


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


Users problems loading all those bloated JavaScript heavy sites




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: