M-RPC: Remote Procedure Call Service for Mobile Clients

One-line summary: Indirect (like I-TCP) RPC, with reliable UDP for wireless part. Automatic rebinding of services to servers after handoff is done under the assumption that certain RPC's are idempotent. Lots of hoopla about how the transport/service layer should support disconnection and data filtering rather than forcing every app to handle it explicitly, but in the end, their implementation falls back on end-to-end solution.

Overview/Main Points (Reviewer's opinion in italics)

• flexible transport layer: different clients/services have different needs, and TCP is problematic on wireless links. (Not clear if this is still true given TCP-snoop.)
• call retries from MSR, to hide from client.
• some support for disconnected operation, e.g. if MH is temporarily disconnected, client RPC should wait for reconnect before retrying call.
• automatic rebinding of services after a move.
• backward compatibility, i.e. can talk to existing RPC servers.
• Low-bandwidth data filters, etc. should be supported in transport layer, rather than forcing each app to do it. I think this violates e2e (end-to-end) argument and is not a good idea.

Authors say that the above reqts. apply particularly to sophisticated apps that engage in long-lived conversations with RPC servers; simpler apps have looser requirements. IMHO, all the more reason to do it e2e!

M-RPC implementation:

• Client/MSR transport is RDP, to avoid forcing client to deal w/wireless losses at app level.
• MSR/server is UDP, for compatibility w/existing servers. MSR looks like a regular RPC client to the server. A problem for schemes that use client netmask or other form of client authentication.
• Clients should bind to services, not servers. Service bindings can be changed by new MSR after a handoff. Clients can also bind to servers for compatibility, or non-idempotent calls (see below).
• Assumption: any call made by binding to a service is idempotent. Ensures that it's OK for new MSR to switch service to a new server if it wants.
• Disconnection: client can setup app-specific callback that is called when disconnection occurs, or when RPC fails due to disconnection. So it's e2e after all.
• Performance: about 4x slower than Sun UDP RPC when no wireless losses. As lossage increases, UDP performance is dominated by retry timeout whereas M-RPC performance is "protected" since RDP is used. Not really big news

Relevance

Flaws

• No mention of how to handle failure semantics with this "split" model. Who assumes responsibility?
• Much ado about supporting disconnectedness and data filtering in transport layer, but current impl. pushes this to application anyway and there is no story for how it might be moved to transport layer.
• 4x perf hit is about what you'd expect from the added roundtrips. No discussion of alternate approaches, but authors' starting assumption is that TCP is bad for wireless. Seems like RPC over TCP-snoop might be OK, if connection is long lived, since it also preserves e2e RPC failure semantics.