RPC Latency Limits The context for this question is the same…
RPC Latency Limits The context for this question is the same as the previous question. A legacy low-latency RPC system for a distributed operating system operates over 100 Gbps Ethernet hardware that occasionally exhibits packet corruption, even when Ethernet CRC checks pass. To guard against such errors, the system currently uses software-based UDP checksums, which add about 180 µs per RPC, contributing roughly 7% of the total latency for a minimal RPC call. An improved integrity verification mechanism is being considered to reduce latency while maintaining correctness. The following 2 approaches are being considered – Hardware-only -> Use NIC checksum offload, no software checksums Hardware Software Combined -> Use NIC checksum offload together with an additional lightweight application-level checksum in the RPC protocol. c) You are now designing a new-generation low-latency RPC system for distributed OS. Your goal is to achieve near-hardware limit RPC performance over modern 400 Gbps Ethernet while ensuring strong end-to-end data integrity. Your teammate argues: “Modern NICs and TCP already guarantee reliability. Adding another checksum layer in RPC just increases latency.” Do you agree/disagree with this statement? Justify your reasoning.