anujkaliaiitd
commented
2 years ago Hi. Thanks for your interest.
Yes, this RPC pattern (which we call nested RPCs) is a weak point for eRPC's wire protocol. eRPC supports nested RPCs (e.g., our Raft implementation uses nested RPCs) and in our experiments it performs well. However, as you mention, RTT measurements are inaccurate and that can (theoretically) cause poor performance during congestion. Retransmission-related issues are a bit unlikely IMO since the RTO is quite high (5 ms).
Hi ,
i have some confusions about the WIRE PROTOCOL part of eRPC.
I know eRPC is designed for a specific pattern (small msg, short-running, \etc ). And It seems that eRPC's wire protocol(client-driven) works well when there are two RPC endpoints send req/resp to each other ( \eg A<----->B).
But Have you considered a scenario that there may be several (>3) RPC endpoints. For instance, A send req to B, but B cannot immediately send response to A until it asks C (obtains a response from C). That is : A ---> B ----> C --->B ---->A
| | | | ------------> | | | | ------------> | | | <------------ | | <------------ | | A B C D???? E???
And the scenario can be more complex, \eg, C needs to ask D for the RPC from B .........
Can eRPC's wire protocol still works in this scenarios? My rough thoughts are that : (1) since eRPC use implicit ACKs(carried by response), RTT measurements may be inaccurate. (2) can client-driven protocol still works? (3) longer delay may trigger retransmission ---- greatly harm the performance.
What do you think about it, are there any mistakes/something i overlook? Thanks in advance.