> He said that he would spend the bulk of the talk on moving away from TCP, but that there is also a need for a lighter-weight remote-procedure-call (RPC) framework. Beyond that, he believes that it no longer makes sense to implement transport protocols in software, so those will need to eventually move into the network interface cards (NICs), which will require major changes to NIC architectures as well.
So basically hardware-accelerated RPCs. I can get behind that in theory, but encoding RPC semantics in hardware sounds like a recipe for extremely slow evolution and very limited hardware choice.
It’s hard to make chatty protocols efficient. The big question we will need to ask ourselves is whether we want to make them cheaper, whether doing so increases the costs for applications that don’t rely on micro optimizations to function correctly. That’s always a danger sign to me.
Not the least of which being things like Meltdown and Spectre creating an ethical dilemma where correct is now much slower than the existing solution. We thought we needed that speed. How many applications function much more poorly when this low level glue layer gets fat and crunchy?
This short paper answers this question and more. I found it a helpful explanation of specifically what TCP design problems Homa is intended to address.
How is this a networking protocol? This reads like a full-blown RPC system built on top of UDP.
They kinda say as much in part one.
Thanks, I should have read that.
> He said that he would spend the bulk of the talk on moving away from TCP, but that there is also a need for a lighter-weight remote-procedure-call (RPC) framework. Beyond that, he believes that it no longer makes sense to implement transport protocols in software, so those will need to eventually move into the network interface cards (NICs), which will require major changes to NIC architectures as well.
So basically hardware-accelerated RPCs. I can get behind that in theory, but encoding RPC semantics in hardware sounds like a recipe for extremely slow evolution and very limited hardware choice.
It’s hard to make chatty protocols efficient. The big question we will need to ask ourselves is whether we want to make them cheaper, whether doing so increases the costs for applications that don’t rely on micro optimizations to function correctly. That’s always a danger sign to me.
Not the least of which being things like Meltdown and Spectre creating an ethical dilemma where correct is now much slower than the existing solution. We thought we needed that speed. How many applications function much more poorly when this low level glue layer gets fat and crunchy?
This short paper answers this question and more. I found it a helpful explanation of specifically what TCP design problems Homa is intended to address.
https://arxiv.org/abs/2210.00714