I-TCP: Indirect TCP for Mobile Hosts

Ajay Bakre and B.R. Badrinath

One-line summary:
By &quottransparently&quot splitting a TCP connection into a MHMSR
and a MSRCH connection, the MHMSR 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

This is a good way to optimize TCP for wireless links, if you don't mind
subtle changes to TCP semantics.

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.