obile etworking M-TCP : TCP for Mobile Cellular Networks Kevin Brown and Suresh Singh Department of Computer Science Univ. of South Carolina ACM Computer Communications Review, Hyun-Jin Kim

obile etworking Introduction – TCP in Mobile Environment Traditional TCP TCP is designed to work on wired networks Negligible medium loss Buffer overflow at routers leads network congestion TCP under wireless mobile networks High BER and frequent disconnections lead packet losses But, TCP simply interprets them as a indication of congestion Significant degradation of end-to-end performance Approaches for improving TCP performance Snoop TCP [1] I-TCP[2] & MTCP[3] M-TCP

obile etworking Former Solutions – SNOOP TCP Snoop module resides at the BS (Base Station) Inspects TCP header of data packets and ACK packets Keeps track of packets in both direction Local retransmission between BS and MH (Mobile Host) Pros Preserves end-to-end TCP semantics Changes are restricted to BS and optionally to MH Cons Under long and frequent disconnections, sender times out Frequent handoffs – snoop module needs to build its cache up

obile etworking Former Solutions – I-TCP & MTCP Split connection protocols FH to BS, BS to MH Wireless connection can even use another transport protocol that suits wireless medium Pros When a handoff occurs, the old BS can deliver the packets of its buffer to the new BS Sender does not concern about wireless environment Cons Breaks end-to-end TCP semantics BS can be a bottleneck BS FHMH FH Socket  MH Socket Wireless TCPStandard TCP

obile etworking M-TCP - Overview TCP connection is split in two at the SH Maintains end-to-end TCP semantics “Persist mode” – keeps timer of sender SH (Supervisor Host) Maintains several MSS (Mobile Support Station) – reduces handoff overheads Serves function of gateway Bandwidth manager, local recovery SH FH (Fixed Host) MH SH-TCP  M-TCP M - TCP TCP MSS

obile etworking M-TCP – The SH-TCP client Goal – keeps the FH’s congestion window size FH uses unmodified TCP to send data to the SH SH-TCP client Passes packets from the FH on to M-TCP Does not ACK those packets until the MH does So, end-to-end TCP semantics are maintained Sends ACK to the sender except ACK for one last byte When the MH is disconnected, sends ACK for the last byte with a window size set to ‘0’ – “persist mode” When a MH regains its connection, it sends a greeting packet This packet allows the sender to leave “persist mode”

obile etworking M-TCP – M-TCP between the SH and MH Goal – fast local recovery from disconnection events Has responds to notifications of wireless link connectivity M-TCP at the MH is notified the connection is lost Freezes all M-TCP timer Connection is regained Unfreezes all M-TCP timers MH sends a specially marked ACK to M-TCP at the SH which contains the highest received sequence number How to determine the connection is lost? Assumes the SH assigns fixed bandwidth No ACK from the MH within Timeout of M-TCP (See next slide)

obile etworking M-TCP – How to estimate RTO ? (1): F TCP RTO (2+4): S TCP RTO (3): S M-TCP RTO Therefore (1) = (2+4)+(3) FH SH MH RTT(1) (2) (3) (4) Therefore, the SH can estimate RTO between itself and the MH The SH can determine the connection is lost by using estimated RTO

obile etworking M-TCP – Other Issues Compressed M-TCP Packets are compressed at the SH and decompressed at the MH When a handoff occurs Freezes connection state Some of the state about the connection is passed to the new SH Removes the contents of the socket buffers at the old SH Unfreezes connection state Connection setup Two different operations for setting up FH  SH and SH  MH Transparent SH FH  MH SH automatically creates sockets for the FA and the MH

obile etworking M-TCP - Normal Transmission (1/2) SH-TCPM-TCP This is for freezing sender’s window. cwnd=2 SH cwnd=3 (2,1) buffered

obile etworking M-TCP - Normal Transmission (2/2) SH-TCP M-TCP This is for freezing sender’s window. 2 cwnd=3cwnd=5 SH (4,3) buffered

obile etworking M-TCP - Disconnection SH-TCP M-TCP 4 Freezing Notify disconnection Freezing (8,7,6,5) buffered cwnd=5 SH cwnd=6

obile etworking M-TCP - Recovery SH-TCP M-TCP Notify reconn cwnd=6cwnd=9 (8,7,6,5) buffered SH

obile etworking M-TCP - Performance Evaluation SH FH1 Distance Sender MH FH2 Close Sender 14 Hops 4 Hops Emulated 32kbps Link Experimental set up All nodes are Pentium PCs Wireless link is emulated at the SH 32Kbps downlink, 8Kbps uplink Disconnection length – 0.5 ~ 4.5 sec Cell latency mean – 5 sec (12 disconnection events in 5 sec)

obile etworking M-TCP - Performance Evaluation M-TCP vs TCP performance

obile etworking M-TCP - Performance Evaluation Compressed M-TCP vs normal M-TCP

obile etworking M-TCP - Performance Evaluation M-TCP processing time

obile etworking Conclusion M-TCP Solution to improve TCP in mobile networks Splits TCP connection, but it makes an effort to maintain end-to- end TCP semantics Persist mode Still exists problems When the MH sends cumulative ACK When the FH finishes to send data High processing at SH Does M-TCP really maintain end-to-end TCP semantics?

obile etworking References [1] H. Balakrishnan, S.Seshan, and Randy Katz, “Improving Reliable Transport and Handoff Performance in Cellular Wireless Networks”, Wireless Networks, Vol 1 No.4 December 1995 [2] A.Bakre and B.R.Badrinath, “I-TCP: Indirect TCP for Mobile Hosts”, IC on Distributed Computing Systems 1995 [3] R. Yavatkar and N. Bhagawat, “Improving End-to-End Performance of TCP over Mobile Internetworks”, IEEE Workshop on Mobile Computing Systems and Applications, 1994