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

Having lived through a production datacenter meltdown due to software engineers throwing away TCP, along with stuff like slow start and congestion control, and obliterating ethernet switch buffers with UDP, I'm a bit concerned as to how QUIC is supposed to be used in order to avoid that?

If your fabric has end-to-end flow control this would be fine, but this seems like it could be greatly misused and should come with some warning labels.




https://web.archive.org/web/20220328033933/https://datatrack...

They copied directly from TCP and made several adjustments to improve signalling.


Oh that's a relief.

Looks like someone finally did the "lets replace TCP with UDP" job right.

And it looks like a hell of a lot of work.


That’s the hope, anyway. It’s hard to compete with decades of TCP refinement but at least there’s some big guns behind making this work.

There’s a lot of thought that has gone into QUIC and the protocol has several rules and mechanisms to prevent problems, such as the 3x amplification limit. Both the browser authors and server side (e.g. google) are on the lookout for problems and how they can improve on them.


There's a new Homa protocol specifically designed for data center to replace TCP by Ousterhout (TCL/TK and Raft author).

Ousterhout is now looking for people to test the Homa protocol for the data center to improve its implementation [1].

[1]Linux implementation of Homa, a protocol to replace TCP for low-latency RPC:

https://news.ycombinator.com/item?id=28440542




Join us for AI Startup School this June 16-17 in San Francisco!

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

Search: