I-TCP: Indirect TCP for Mobile Hosts

One-line summary: By "transparently" splitting a TCP connection into a MH<->MSR and a MSR<->CH connection, the MH<->MSR connection can be optimized, and congestion control and retransmissions on the wireless link isolated from those on the wireline link - at the price of breaking end-to-end TCP semantics and inducing extra copying overhead.

Overview/Main Points

• Problems with TCP: All of the usual backoff and disconnection problems with TCP and wireless links are given as motivation for I-TCP.
• I-TCP: The TCP connection between the mobile host (MH) and the correspondent host (CH) is split at the mobility support router (MSR). The connection between the MSR and MH has independent, optimized flow and congestion control from the MSR to CH link. In fact, a separate transport protocol can be used (although they didn't do this).
• MSR state: Mobile-IP is used to deal with the mobility of the MH. The MSRs transfer the split connection state when a handoff occurs to a new MSR.
• Changes to TCP semantics: Because the connection is split, separate acknowledgements are generated for the MH to MSR and MSR to CH links - the acknowledgements are not end-to-end. The link characteristics are also different - the MSR to MH link is very fragile. Because they use Mobile-IP, all other TCP semantics are preserved.
• Performance: I-TCP is strictly better than regular TCP. If there are no hand-offs, then the performance gained by the optimized MSR to MH link outweighs the overhead of copying packets across the links. If there are hand-offs across cells, the fact that congestion control and slow-start for the MSR to CH were avoided resulted in a big win. (Although the window size for the MSR to CH link did decrease, because incoming packets were being buffered and not delivered during the handoff.) Performance in WANs is even better than performance in LANs, because retransmissions and recovery from congestion control on the wireless link is decoupled from the WAN wireline link.
• Implementation details: The I-TCP layer is a user-level process, meaning extra overhead in going from kernel space to user space. This overhead was claimed to be far less than the gain I-TCP provided. Another detail is that forwarding pointer route optimizations between MSRs were used.

Relevance

Flaws

• I have to believe that the copying overhead is going to bite them eventually, especially for high-throughput WLANs and heavily loaded MSRs, or for real-time traffic with hard delivery latency requirements.
• What happens if I-TCP is used multiple times over multiple wireless hops? A lot of unnecessary copying is done, and now the end-to-end semantics are violated multiple times.
• Applications running on the MH must be relinked with the I-TCP library.
• The state-transfer between MSRs implies an inflated handoff latency.