This document discusses various transport layer protocols for mobile networks. It begins by describing TCP and its mechanisms for congestion avoidance, flow control, slow start, and retransmission. It then covers several TCP variants including Tahoe, Reno, and Vegas. It also discusses indirect TCP, Snoop TCP, and Mobile TCP which aim to optimize TCP for wireless networks by handling retransmissions locally or splitting the connection. The document provides details on the algorithms and functioning of these different protocols.

1. Mobile Transport Layer
Prepared By :
Maulik Patel

2. Outline
 TCP and its Usability : Congestion Avoidance, Flow control
 Slow Start and Retransmission
 TCP Variants : Tahoe, Reno and Vegas
 Indirect TCP
 Snoop TCP and Mobile TCP
 Transaction Oriented TCP and TCP over 2.5G/3G

3. TCP and Its Usability
 Reliable ordered delivery
 TCP has built-in mechanisms to behave in a ‗network friendly‘
manner.
 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

4. Cont…
 End-to-end semantics
Acknowledgements sent to TCP sender confirm delivery
of data received by TCP receiver
Ack for data sent only after data has reached receiver

5. Congestion
 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.

6. Effect of Congestion
 Congestion causes packet loss
 Results in retransmission
 Reduces data throughput

7. Congestion Avoidance
 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.

9. Flow Control
 Flow control refers to a set of procedures used to restrict the
amount of data that the sender can send before waiting for
acknowledgment.
 limits the rate a sender transfers data to guarantee reliable
delivery.
 The receiver continually hints the sender on how much data can be
received.
 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

10. Slow Start
 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
Congestion Window(cwnd).
 Moreover, slow start is slower than sending a full advertised
window‘s worth of packets all at once.

11. Cont…
 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!)

12. Slow Start
Add one packet
per ACK
Slow Start
Source Destination

13. Cont…
 However, in the second case the source has more
information. The current value of cwnd can be saved as a
congestion threshold.
 This is also known as the ―slow start threshold‖ ssthresh.

14. Retransmission
 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-
grain timeouts.
 Fast retransmit does not eliminate all the timeouts due to
small window sizes at the source.

15. Fast Retransmission
Based on three
duplicate ACKs
 Receipt of three duplicate ACKs, the TCP Sender
retransmits the lost packet.
Packet 1
Packet 2
Packet 3
Packet 4
Packet 5
Packet 6
Retransmit
packet 3
ACK 1
ACK 2
ACK 2
ACK 2
ACK 6
ACK 2
Sender Receiv er

16. TCP Recap...
 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
occurs

17. TCP Algorithms:
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

18. TCP Variants :
 TCP-Tahoe:
implements the slow start, congestion avoidance,
and fast retransmit algorithms
 TCP-Reno:
implements the slow start, congestion avoidance,
fast retransmit, and fast recovery algorithms
 TCP-Vegas:
Improvement of TCP Reno
New Retransmission mechanism.

19. TCP Tahoe
 Two major congestion control schema use
Slow start and congestion avoidance
Increase cwnd size
Fast Retransmission
Detect congestion
 Problem
Take a complete timeout interval to detect a packet loss

20. TCP Tahoe‘s Fast Retransmit
1. Sender
receives 3
dupACKS.
2. Sender infers
that the
segment is
lost.
3. Sender re-
sends the
segment
immediately!
4. Sender
returns to
slow-start.
cwnd = 1
cwnd = 2
cwnd = 4
3 duplicate
ACKs
fast-retransmit
of segment 4
S R

21. TCP Tahoe’s Graph

22. (TCP Reno)
Fast Retransmit & Fast Recovery
 After receiving 3 dupACKS:
1. Retransmit the lost segment.
2. Set ssthresh = flight size/2.
3. Set cwnd = ssthresh, and ndupacks = 3.
 If dupACK arrives:
 ++ ndupacks
 Transmit new segment, if allowed.
 If new ACK arrives:
 ndupacks = 0
 Exit fast recovery.
 If RTO expires:
 ndupacks = 0
 Perform slow-start - ( ssthresh = flight size/2, cwnd = 1 )

23. TCP Reno vs TCP Tahoe

24. TCP Vegas
 Developed by Brakmo, O'Malley & Peterson
[SIGCOMM,1994]
 TCP Vegas emphasis on packet delay, not packet loss.
 Sender-side protocol
Inter-operates with other TCP variants
 Depends heavily on accurate calculation of the Base RTT
value.
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.

25. TCP Vegas
 Adjust window size even before packet loss
 Adjust window based on difference between actual
and expected throughput
 Advantage
Detects losses faster than TCP Reno and also
recover from multiple drops more efficiently.
 Disadvantage
On heavily traffic it react same as TCP Reno.
Vegas are not stabilize if buffer are too small.
Fairness issues of Vegas still unresolved

26. TCP Vegas new
retransmission mechanism
 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
estimate
 So no need to wait for 3 dupack, send retransmite packet

27. Indirect TCP
 Split a TCP connection at the foreign agent into 2 TCP
connections
 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

28. Cont…

29. Cont…
 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.

30. I-TCP Socket and State
Migration

31. 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

32. Cont…
 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
networks.

33. 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
might crash.
 Higher latency possible
 due to buffering of data within the foreign agent and
forwarding to a new foreign agent
 Security issue
 The foreign agent must be a trusted entity.

34. Snoop TCP
 Indirect TCP
 2 TCP sessions.
 Snoop TCP
 One TCP session.
 The access point snoops into the traffic and buffers
packets for fast re-transmission.

35. Cont…

36. Cont…
 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
filters ACKs

37. Cont…
 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
network
 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

38. Snoop TCP: Packet Delivery

39. Cont…
 Advantages
 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
no enhancements.
 Problems
 snooping TCP does not isolate the wireless link as good as
I-TCP
 snooping might be useless depending on encryption
schemes

40. Mobile TCP
 What if the mobile node is disconnected?
 I-TCP
 more packets are buffered at AP.
 Snooping TCP
 no more snooping
 Missing acknowledgement, TCP goes to slow-start.
 Mobile TCP
 Improve efficiency.
 Special handling of lengthy and/or frequent
disconnections.

41. Cont…

42. Cont…
 M-TCP splits as I-TCP does
 unmodified TCP fixed network to supervisory host (SH)
 optimized TCP SH to MH
 Supervisory host
 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

43. Cont…
 Advantages:
 End-to-end semantics.
 When mobile host is disconnected, it avoids useless
retransmissions and slow-start.
 No buffering, handover is easy.
 Disadvantages:
 Packet loss at the wireless link propagates back to
sender.
 Not a good idea for heavy traffic.

44. Transaction Oriented TCP
 TCP phases
connection setup, data transmission, connection release
using 3-way-handshake needs 3 packets for setup and
release, respectively
thus, even short messages need a minimum of 7 packets!
 Transaction oriented TCP
RFC1644, T-TCP, describes a TCP version to avoid this
overhead
connection setup, data transfer and connection release
can be combined
thus, only 2 or 3 packets are needed

45. Cont…
 Advantage
efficiency
 Disadvantage
requires changed TCP
mobility not longer transparent

46. TCP over 2.5/3G
Wireless Networks
 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
 Suggestions
 Large (initial) sending windows, large maximum transfer unit, selective
acknowledgement, explicit congestion notification, time stamp, no header
compression
 Widespread use
 i-mode running over FOMA

47. Performance
Enhancing Proxies
 RFC 3135
Transport layer
Local retransmissions and acknowledgements
Additionally on the application layer
Content filtering, compression, picture downscaling
E.g., Internet/WAP gateways
Web service gateways?
Mobile system
PEP
Comm. partner
wireless
Internet

48. Cont…
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

49. Summary
 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

50. Cont…
 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
problems
Link-level recovery
Split protocols
End-to-end protocols

51. References
 [1]IEEE:TCP-FIT: An improved TCP congestion control algorithm and its
performance
 [2]IEEE: Fast TCP flow control with differentiated services
 [3]Afanasyev, A.; N. Tilley, P. Reiher, and L. Kleinrock (2010). "Host-to-host
congestion control for TCP―
 [4] Jacobson, Van; Karels, MJ (1988). ―Congestion avoidance and control‖
 [5]http://www.scribd.com/doc/63483753/Indirect-TCP-Snooping-TCP-Mobile-
TCP-Mobile-Transport-Layer#download
 [6]Jian Ma, "A simple Fast TCP flow control in IP network or IP/ATM subnet – a
significant improvement over IP", November, 1997
 [7]A Comparative Analysis of TCP Tahoe, Reno, New-Reno, SACK and Vegas
http://inst.eecs.berkeley.edu/~ee122/fa05/projects/Project2/SACKRENEVEGAS.p
df

52. Thank You