Mobile Transport Layer
Prepared By :
TCP and its Usability : Congestion Avoidance, Flow control
Slow Start and Retransmission
TCP Variants : Tahoe, Reno and Vegas
Snoop TCP and Mobile TCP
Transaction Oriented TCP and TCP over 2.5G/3G
TCP and Its Usability
Reliable ordered delivery
TCP has built-in mechanisms to behave in a ‗network friendly‘
Guarantees that packet will be delivered in same order in
which they were sent
Implements congestion avoidance and control
Reliability achieved by means of retransmissions if necessary
Acknowledgements sent to TCP sender confirm delivery
of data received by TCP receiver
Ack for data sent only after data has reached receiver
Congestion in a network may occur if the load on the
network—the number of packets sent to the network—is
greater than the capacity of the network—the number of
packets a network can handle.
Congestion occurs when bandwidth is insufficient and
network data traffic exceeds capacity.
Effect of Congestion
Congestion causes packet loss
Results in retransmission
Reduces data throughput
In the congestion avoidance algorithm, the size of congestion
window increases additively until congestion is detected.
It maintains a network congestion state after reducing the
initial data load.
Flow control refers to a set of procedures used to restrict the
amount of data that the sender can send before waiting for
limits the rate a sender transfers data to guarantee reliable
The receiver continually hints the sender on how much data can be
When the receiving host's buffer fills, the next acknowledgment
contains a 0 in the window size, to stop transfer.
TCP uses an end-to-end flow control protocol to avoid having the
sender send data too fast for the TCP receiver to receive and
process it reliably
Linear additive increase takes too long to ramp up a new TCP
connection from cold start
Beginning with TCP Tahoe, the slow start mechanism was
added to provide an initial exponential increase in the size of
Moreover, slow start is slower than sending a full advertised
window‘s worth of packets all at once.
The source starts with cwnd = 1.
Every time an ACK arrives, cwnd is incremented.
cwnd is effectively doubled per RTT.
Two slow start situations:
At the very beginning of a connection.
When the connection goes dead waiting for a timeout to
occur (i.e, the advertized window goes to zero!)
Add one packet
However, in the second case the source has more
information. The current value of cwnd can be saved as a
This is also known as the ―slow start threshold‖ ssthresh.
Coarse timeouts remained a problem, and Fast retransmit
was added with TCP Tahoe.
Since the receiver responds every time a packet arrives, this
implies the sender will see duplicate ACKs.
Generally, fast retransmit eliminates about half the coarse-
Fast retransmit does not eliminate all the timeouts due to
small window sizes at the source.
Based on three
Receipt of three duplicate ACKs, the TCP Sender
retransmits the lost packet.
Sender Receiv er
TCP is a reliable protocol
Ensuring reliability by requiring receiver‘s acknowledgement
TCP uses cumulative ack. schema
TCP start timer, maintains for retransmission
TCP is end-to-end delivery oriented mechanism
TCP can work directly on wireless but it require some
modification in TCP as it have mobility so high bit error rate
Four algorithms used commonly in TCP implementations
Slow Start - Every ack increases the sender‘s window (cwnd)
size by 1
Congestion Avoidance - Reducing sender‘s window size by
half at experience of loss, and increase the sender‘s window at
the rate of about one packet per RTT
Fast Retransmit - Don‘t wait for retransmit timer to go off,
retransmit packet if 3 duplicate acks received
Fast Recovery - Since duplicate ack came through, one packet
has left the wire. Perform congestion avoidance, don‘t jump
down to slow start
TCP Variants :
implements the slow start, congestion avoidance,
and fast retransmit algorithms
implements the slow start, congestion avoidance,
fast retransmit, and fast recovery algorithms
Improvement of TCP Reno
New Retransmission mechanism.
Two major congestion control schema use
Slow start and congestion avoidance
Increase cwnd size
Take a complete timeout interval to detect a packet loss
TCP Tahoe‘s Fast Retransmit
2. Sender infers
3. Sender re-
cwnd = 1
cwnd = 2
cwnd = 4
of segment 4
Developed by Brakmo, O'Malley & Peterson
TCP Vegas emphasis on packet delay, not packet loss.
Inter-operates with other TCP variants
Depends heavily on accurate calculation of the Base RTT
If it is too small then throughput of the connection will be
less than the bandwidth available while if the value is too
large then it will overrun the connection.
Adjust window size even before packet loss
Adjust window based on difference between actual
and expected throughput
Detects losses faster than TCP Reno and also
recover from multiple drops more efficiently.
On heavily traffic it react same as TCP Reno.
Vegas are not stabilize if buffer are too small.
Fairness issues of Vegas still unresolved
TCP Vegas new
Keeps track of when each segment was sent and it also
calculates an estimate of the RTT.
Whenever a duplicate acknowledgement is received it checks
to see if the (current time-segment transmission time)> RTT
So no need to wait for 3 dupack, send retransmite packet
Split a TCP connection at the foreign agent into 2 TCP
hosts in the fixed part of the network do not notice the
characteristics of the wireless part
no changes to the TCP protocol for hosts connected to
the wired Internet, millions of computers use (variants
of) this protocol
optimized TCP protocol for mobile hosts
The access point acts as proxy in both directions.
AP acknowledges to both the sender and receiver.
Re-transmission on wireless links is handled locally.
During handover, the buffered packets, as well as the system
state (packet sequence number, acknowledgements, ports,
etc), must migrate the new agent.
Advantages of I-TCP
No changes in the fixed network necessary, no changes for
the hosts (TCP protocol) necessary, all current optimizations
to TCP still work
Simple to control, mobile TCP is used only for one hop
between, e.g., a foreign agent and mobile host
transmission errors on the wireless link do not propagate
into the fixed network
therefore, a very fast retransmission of packets is possible,
the short delay on the mobile hop is known
It is always dangerous to introduce new mechanisms in a
huge network without knowing exactly how they behave.
New optimizations can be tested at the last hop, without
jeopardizing the stability of the Internet.
It is easy to use different protocols for wired and wireless
Disadvantages of I-TCP
Loss of end-to-end semantics
an acknowledgement to a sender no longer means that a
receiver really has received a packet ---foreign agents
Higher latency possible
due to buffering of data within the foreign agent and
forwarding to a new foreign agent
The foreign agent must be a trusted entity.
2 TCP sessions.
One TCP session.
The access point snoops into the traffic and buffers
packets for fast re-transmission.
Transparent extension of TCP within the foreign agent
changes of TCP only within the foreign agent
buffering of packets sent to the mobile host
lost packets on the wireless link (both directions!) will be
retransmitted immediately by the mobile host or foreign
agent, respectively (so called ―local‖ retransmission)
the foreign agent therefore ―snoops‖ the packet flow and
recognizes acknowledgements in both directions, it also
Data transfer to the mobile host
FA buffers data until it receives ACK of the MH, FA detects
packet loss via duplicated ACKs or time-out
Fast retransmission possible, transparent for the fixed
FA detects packet loss on the wireless link via sequence
numbers, FA answers directly with a NACK to the MH
MH can now retransmit data with only a very short delay
End-to-end semantics is preserved.
Handover is easy. I-TCP requires a careful handover of the
system state. Here it falls back to the standard solution if
snooping TCP does not isolate the wireless link as good as
snooping might be useless depending on encryption
What if the mobile node is disconnected?
more packets are buffered at AP.
no more snooping
Missing acknowledgement, TCP goes to slow-start.
Special handling of lengthy and/or frequent
M-TCP splits as I-TCP does
unmodified TCP fixed network to supervisory host (SH)
optimized TCP SH to MH
no caching, no local retransmission
monitors all packets, if disconnection detected
set sender window size to 0
sender automatically goes into persistent mode
old or new SH reopen the window
When mobile host is disconnected, it avoids useless
retransmissions and slow-start.
No buffering, handover is easy.
Packet loss at the wireless link propagates back to
Not a good idea for heavy traffic.
Transaction Oriented TCP
connection setup, data transmission, connection release
using 3-way-handshake needs 3 packets for setup and
thus, even short messages need a minimum of 7 packets!
Transaction oriented TCP
RFC1644, T-TCP, describes a TCP version to avoid this
connection setup, data transfer and connection release
can be combined
thus, only 2 or 3 packets are needed
TCP over 2.5/3G
Fine tuning today‘s TCP
Learn to live with
Data rates: 64 kbit/s up, 115-384 kbit/s down; asymmetry: 3-6, but also up
to 1000 (broadcast systems), periodic allocation/release of channels
High latency, high jitter, packet loss
Large (initial) sending windows, large maximum transfer unit, selective
acknowledgement, explicit congestion notification, time stamp, no header
i-mode running over FOMA
Local retransmissions and acknowledgements
Additionally on the application layer
Content filtering, compression, picture downscaling
E.g., Internet/WAP gateways
Web service gateways?
Big problem: breaks end-to-end semantics
Disables use of IP security
Choose between PEP and security!
RFC 3150 (slow links)
Recommends header compression, no timestamp
RFC 3155 (links with errors)
States that explicit congestion notification cannot be used
TCP is a complex protocol
Minimal support from underlying protocols
Indirect observation of network environment
Large number of competing flows from different hosts
Congestion avoidance is still a research issue
TCP does not perform well in a wireless environment where
packets are usually lost due to bit errors, not congestion
Schemes have been proposed to address TCP performance
IEEE:TCP-FIT: An improved TCP congestion control algorithm and its
IEEE: Fast TCP flow control with differentiated services
Afanasyev, A.; N. Tilley, P. Reiher, and L. Kleinrock (2010). "Host-to-host
congestion control for TCP―
 Jacobson, Van; Karels, MJ (1988). ―Congestion avoidance and control‖
Jian Ma, "A simple Fast TCP flow control in IP network or IP/ATM subnet – a
significant improvement over IP", November, 1997
A Comparative Analysis of TCP Tahoe, Reno, New-Reno, SACK and Vegas