2 ms·
> We've already seen people build a number of similar systems on UDP including HTTP replacements that have delivered value for clients doing lots of parallel re
by KaiserPro 4y ago
> We've already seen people build a number of similar systems on UDP including HTTP replacements that have delivered value for clients doing lots of parallel requests on the WAN.
HTTP isn't low latency. Spending all that effort porting everything to a discreet message based network, only to have HTTP semantics running over the top is a massive own goal.
as for WAN, thats a whole different kettle of fish. You need to deal with huge latencies, whole integer percentage of packet loss, and lots of other wierd shit.
In that instance you need to create a protocol to tailor to your needs. Are you after bandwidth efficiency, or raw speed? or do you need to minimise latency? All three things require completely different layouts and tradeoffs.
I used to work for a company that shipped TBs from NZ & Aus to LA via london. We used to use aspera, but thats expensive. So we made a tool that used hundreds of TCP connections to max out our network link.
For specialist applications, I can see a need for something like homa. But for 95% of datacenter traffic, its just not worth the effort.
That paper is also fundamentally flawed, as the OP has rightly pointed out. Just because Ousterhout is clever, doesn't make him right.
- Karrot_Kream 4y agoWhat about HTTP/2 or HTTP/3 do you see poses large latency problems? Both of those do away with HTTP HOL blocking (not TCP HOL blocking) and allow parallel streams. Homa proposes introducing a transport level protocol with request/response semantics specifically to accommodate protocols like HTTP which operate using requests and responses.
- KaiserPro 4y agoHTTP/2 is the king of HOL blocking. Its a single TCP connection in which everything is multiplexed at the app level. It was almost like it was designed to exploit the worst parts of TCP. It was and is a stupid design, they were clearly told about the drawbacks, both in mobile and for transfer of larger website. They chose to ignore it. The key thing is that HTTP is not designed to be low latency. If latency is important to you, then you need to make your protocol bespoke for that application. HTTP/3 has a much better TLS connection process, which means that the cost of creating a connection is much lower. QUIC is much more configurable in terms of per steam or connection flowcontrol. Yes, homa has request/reply semantics, but not in the way that HTTP needs. Homa is optimised for low latency small messages, in a small hop, transparent network. HTTP is a file access protocol with a general data channel hammered in. Sure it'll work in a DC type network, but its also got to deal with lossy, high latency networks.