M-TCP : TCP for Mobile Cellular Networks
Kevin Brown and Suresh Singh
Department of Computer Science
Univ. of South Carolina
ACM Computer Communications Review, 1997
2005.07.29
Hyun-Jin Kim
2017-07-31
1
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
2017-07-31
2
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
2017-07-31
3
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
FH
Standard TCP
MH
Wireless TCP
FH Socket MH Socket
2017-07-31
4
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)
MSS
TCP
MH
M - TCP
SH-TCP M-TCP
2017-07-31
5
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”
2017-07-31
6
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)
2017-07-31
7
obile
etworking
M-TCP – How to estimate RTO ?
FH
SH
MH
(2)
(3)
RTT(1)
(4)
(1): FTCPRTO
(2+4): STCPRTO
(3): SM-TCPRTO
Therefore (1) = (2+4)+(3)
2017-07-31
Therefore, the SH can estimate RTO
between itself and the MH
The SH can determine the connection
is lost by using estimated RTO
8
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
2017-07-31
9
obile
etworking
M-TCP - Normal Transmission (1/2)
(2,1) buffered
SH
2 1
2 1
1
1 2
cwnd=2
cwnd=3
SH-TCP
2
M-TCP
1 2
This is for freezing sender’s window.
2017-07-31
10
obile
etworking
M-TCP - Normal Transmission (2/2)
(4,3) buffered
SH
4 3
cwnd=5
cwnd=3
4 3
2 3
3 4
M-TCP
SH-TCP
4
2
3 4
This is for freezing sender’s window.
2017-07-31
11
obile
etworking
M-TCP - Disconnection
(8,7,6,5) buffered
SH
8 7 6 5
cwnd=5
cwnd=6
4
Freezing
Freezing
SH-TCP
M-TCP
Freezing
4
2017-07-31
Notify
disconnection
12
obile
etworking
M-TCP - Recovery
(8,7,6,5) buffered
16
15
14
13
12
11
10
9
SH
4
Notify reconn.
cwnd=9
cwnd=6
5 6 7
2017-07-31
5 6 7 8
M-TCP
SH-TCP
8
5 6 7 8
5 6 7 8
13
obile
etworking
M-TCP - Performance Evaluation
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)
FH1
SH
Distance Sender
14 Hops
Emulated
32kbps Link
MH
FH2
Close Sender
4 Hops
2017-07-31
14
obile
etworking
M-TCP - Performance Evaluation
M-TCP vs TCP performance
2017-07-31
15
obile
etworking
M-TCP - Performance Evaluation
Compressed M-TCP vs normal M-TCP
2017-07-31
16
obile
etworking
M-TCP - Performance Evaluation
M-TCP processing time
2017-07-31
17
obile
etworking
Conclusion
M-TCP
Solution to improve TCP in mobile networks
Splits TCP connection, but it makes an effort to maintain end-toend 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?
2017-07-31
18
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
2017-07-31
19
obile
etworking