1. ECE544: Communication Networks-II Spring 2010
Sumit Rangwala
Includes teaching materials from S. Gopal, L. Peterson, and D. Raychaudhuri

2. Today’s Lecture
Introduction to transport protocols
UDP
TCP
RTP

3. The Disconnect Applications running on hosts need to communicate
Guaranteed Service
Best-effort R1
ETH
FDDI IP R2
FDDI
PPP IP R3
PPP
ETH IP IP
ETH IP
ETH
Applications running on hosts need to communicate
Require some guarantees from the underlying layer
Network Layer (IP) provides only best-effort communication services
Only between hosts (not applications)

4. Transport Protocol Transport protocol
Host1
Host8
Appl.
Appl.
TCP/UDP
TCP/UDP R1
ETH
FDDI IP R2
FDDI
PPP IP R3
PPP
ETH IP IP IP
ETH
ETH
Transport protocol
Provides services required by applications using the services provides by the network layer
The Transport Layer is the lowest layer in the network stack that is an end-to-end protocol

5. Transport Protocols Applications requirements vs. IP layer limitations
Guarantee message delivery
Network may drop messages. How?
Deliver messages in the same order they are sent
Messages may be reordered in networks and incurs a long delay. How?
Delivers at most one copy of each message
Messages may duplicate in networks. How?
Support arbitrarily large message
Network may limit message size. Why?
Support synchronization between sender and receiver
Allows the receiver to apply flow control to the sender
Support multiple application processes on each host
Network only support communication between hosts
Many more
Design just a few transport protocols to meet most of the current and future application requirements
Each satisfies the requirements for a class of applications
Many applications=>few transport protocols

6. Most Popular Transport Protocols
User Datagram Protocol (UDP)
Support multiple applications processes on each host
Option to check messages for correctness with CRC check
Transmission Control Protocol (TCP)
Ensures reliable delivery of packets between source and destination processes
Ensures in-order delivery of packets to destination process
Other services
Real Time Protocol (RTP)
Serves real-time multimedia applications
Moves decision making to the applications
Runs over UDP
TCP, UDP and RTP satisfy needs of the most common applications
Applications requiring other functionality usually use UDP for transport protocol, and implement additional features as part of the application

7. User Datagram Protocol (UDP): Demultiplexing
Service: Support for multiple processes on each host to communicate
Issue: IP only provides communication between hosts (IP addresses)
Solution
Add port number and associate a process with a port number
4-Tuple Unique Connection Identifier: [SrcPort, SrcIPAddr, DestPort, DestIPAddr ]
Appl process
UDP IP
Appl process
UDP IP 16 31
SrcPort
DesPort
Length
Checksum
Payload
Network
UDP Packet Format

8. User Datagram Protocol (UDP): Error Detection
Service: Ensure message correctness
Issue: Packet corruption in transit
Solution
Use Checksum. Why isn’t IP checksum enough?
Includes UDP header, payload, pseudo header
Pseudo header
Protocol number, source IP address, destination IP address, and UDP length 16 31
SrcPort
DesPort
Length
Checksum
Payload

9. Transmission Control Protocol (TCP)
First proposed by Vinton Cerf and Robert Kahn, 1974
TCP/IP enabled computers of all sizes, from different vendors, different OSs, to communicate with each other.
Used by 80% of all traffic on the Internet
Reliable, in-order delivery, connection-oriented, bye-stream service

10. TCP: Connection-oriented
Service: Connection-oriented
Application states the destination once
Issue: IP is connection-less
Solution: TCP maintains the connection state
Connection Establishment
Connection Termination

11. A Simple File Transfer Connection Establishment
Server:
passive open and wait for connection (on a port)
Client:
Active open and initialize connection establishment
After connection establishment
Data transport (more later)
Terminate connection
Both sides independently close their half of the connection

12. TCP: Packet Format Flags Sequence number Acknowledgement
SYN, FIN, ACK, RESET, URG, PUSH
Sequence number
Sequence number of the first byte of data in the segment
It is an abstract number (more later)
Acknowledgement
Next sequence number expected from the sender

13. Connection Establishment
Active participant
(client)
Passive participant
(server)
SYN, Seq#=x
SYN+ACK, Seq#=y
Ack#=x+1
ACK, Ack#=y+1
Data+ACK
Connection
Establishment
Data
transport
Server
Informs TCP about the listening port
Up-call registration
Client
Performs three way handshake
SYN and ACK flags in the header are used
Initial Sequence numbers x and y selected at random
Why?

14. Connection Termination
FIN
FIN-ACK
ACK
DATA
Data write
Data ACK
Any side can terminate the connection
Each side closes its half of the connection independently
A connection may be half-opened
Can only receive data

15. TCP State-Transition
Max segment lifetime (MSL): 120 sec (recommended)

16. TCP: Byte-stream Service: Byte-stream
Application reads or writes a stream of bytes to the transport
Issue: IP is packet-oriented
Solution: TCP maintains a local buffer
Chop the stream into packets and transmit (sender)
Coalesce data from packets to form a stream (receiver)
Issues?

17. TCP: Reliable and Ordered Delivery
Service: Reliable Delivery of byte-stream
Solution: Sliding Window Protocol
Studied earlier
Buffer size at the receiver should be at least receiver window size
Receiving Appl
Sending Appl
LastByteRead
TCP
LastByteWritten
TCP
NextByteAcked
LastByteRcvd
LastByteAcked
LastByteSent
Receiver Window Size
Receiver Window Size
But what if the receiving application cannot read data fast enough?

18. Slow Receiver
Receiver cannot read bytes at the speed the network is delivering data
Requires a buffer > receiver window size
If receiver window size is kept constant, in worst case requires infinite buffer
Receiving Appl
Sending Appl
LastByteRead
TCP
LastByteWritten
TCP
NextByteExpected
LastByteRcvd
LastByteAcked
LastByteSent
< Receiver Window Size
Receiver Window Size

19. TCP: Flow Control Flow Control
“Prevent sender from overrunning the capacity (buffer) of the receiver”
Solution: Use adaptive receiver window size
Goal is to keep (C) – (A) < MaxRcvBuffer
Every packet carries ACK and AdvertisedWindow
Sending Appl
Receiving Appl
LastByteAcked (J)
(K) LastByteSent
(I) LastByteWritten
(B)
NextByteExpected
(C)
LastByteRcvd
LastByteRead
(A)
TCP
LastByteSent (K) – LastByteAcked (J) <= AdvertisedWindow
EffWin = AdvertisedWin -
(LastByteSent-LastByteAcked)
AdvertisedWindow = MaxRcvBuffer-
((NextByteExp-1)-LastByteRead)
LastByteWritten – LastByteAcked <= MaxSendBuffer

20. Sequence Number Wrap Around
Protect against SequenceNum wrap around
Sliding window
Seq # space >= 2 x WinSize
For TCP: 232 >> 2 x 216
Seq # should not wraparound within a MSL (120 sec) period of time
For OC-48 (2.5 Gbps), time until wraparound: 14 sec
TCP extension to the sequence # space for protecting against seq # wrapping around
Add 32-bit timestamp as optional header

21. Keep the Pipe Full AdvertisedWindow: 216=>64 KB TCP Extension:
Big enough to allow the sender to keep the pipe full (assume that the receiver has enough buffer to handle the data)
If RTT = 100 ms,
Delay x Bandwidth = 122 KB for 10 Mbps link
Delay x Bandwidth = 1.2 MB for 100 Mbps link (AdvertisedWindow is not large enough)
TCP Extension:
Scaling factor option for AdvertisedWindow,
e.g., use 16-byte units of data

22. TCP Error Control
Cumulative ACK: ACK the highest contiguous bytes received
Same as studied before
Extension: Selective ACK (SACK), ACK additional blocks of received data in TCP optional header
Timeout Timer
If timeout too soon
unnecessarily retransmit → adds load to network
If timeout too late
Increases latency
Limits the throughput. How?

23. TCP Timeout Issue: RTT in a wide area network varies substantially
Solution: Adaptive Timeout
Original Algorithm:
EstimatedRTT = a x EstimatedRTT + (1-a) x SampleRTT
Timeout = β x EstimatedRTT (β = 2)
Problem
Does not distinguish whether the ACK is for original transmission or retransmission (suggestions?)
Constant β is not good. Why?
Assumes constant variance

24. TCP Timeout Karn/Partridge Algorithm
Whenever TCP retransmits a segment, it stops taking samples of the RTT
Only measure SampleRTT for segments that have have been sent only once
Each time TCP retransmits, set the next timeout to be twice the last timeout
Relieves congestion
Jacobson/Karels Algorithm: Adaptive variance (uses mean variance)
Difference = SampleRTT - EstimatedRTT
EstimatedRTT = EstimatedRTT + (d x Difference) → (same as in original)
Deviation = Deviation + d(|Difference|- Deviation)
Timeout = m x EstimatedRTT + f x Deviation
(default: set m = 1 and f= 4 )

25. Triggering Transmission
When to transmit a segment:
small segments subject to large overhead
Reach max segment size (MSS): the size of the largest segment TCP can send without causing the local IP to fragment
MSS = local MTU – IP & TCP header
The sending process explicitly ask the TCP to transmit, “push”

26. TCP Silly Window Syndrome
Sender has MSS bytes of data to send, but window is closed
ACK arrives with a small window
Sender sends a small segment (high overhead)
Receiver advertise a small window
Sender sends a small receive segment
Repeat the above
To solve: Nagle’s Algorithm
When the application have data to send
If both available data and the window >= MSS
Send a full segment
Else
If there is unACKed data in flight
Buffer the new data until an ACK arrives
Send all the new data now

27. TCP Deadlock TCP Deadlock To solve it:
receiver advertises a window size of 0, the sender stops sending data
the window size update from the receiver is lost
To solve it:
the sender starts the persist timer when AdvertisedWindow = 0
When the persist timer expires, the sender sends a small packet

28. TCP Services Connection-oriented Byte-stream service
Reliable and In-order
Flow Control
Error Control
Congestion Control (next session)

29. Even with flow control packets might not reach the destination
Congestion
Source 1
Even with flow control packets might not reach the destination
Dest 1
Source 2
Dest 2
Source 3
When the network cannot support the sender’s rate
Queues at the network elements overflow

30. Congestion Control vs. Flow Control
Mechanism to prevent sender from overrunning the capacity of the network
When network is the bottleneck
Flow Control
Mechanism to prevent sender from overrunning the capacity of the receiver
When receiver is the bottleneck

31. Congestion Control: Design Approach
Maintain another window at the sender called CongestionWindow (cwnd)
CongestionWindow is the max number of packets allowed in the network
Number of unACKed packets at the sender. Why?
Key: How to calculate congestion window (cwnd)
Various approaches possible
TCP estimates it based on observed packet losses
Assumes packet loss as indication of congestion
Since we don’t know whether the network or the receiver is the bottleneck
MaxWindow = MIN(CongestionWindow, AdvertisedWindow)
EffectiveWin = MaxWindow – (LastByteSent – LastByteAcked)

32. TCP Congestion Control
Consist of four mechanisms
Slow Start → (2)
Getting to the equilibrium
Congestion Avoidance → (1)
Maintaining the equilibrium
Fast Retransmit → (3)
Avoiding retransmission timeouts and slow starts
Fast Recovery → (4)
Avoiding unnecessary slow starts

33. Congestion Avoidance: (AIMD)
If no congestion in the network (increase conservatively)
Increase the congestion window additively every RTT
If congestion in the network (decrease aggressively)
Decrease the congestion window multiplicatively, immediately
How is congestion detected?
Estimated (more later)
Every ACK reception
cwnd = cwnd + MSS*(MSS/cwnd)
cwnd in bytes
Every RTT
w = w + 1
w = cwnd in segments
Every ACK reception
w = w + 1/w
w = cwnd in segments
cwnd = cwnd/2
cwnd in bytes

34. Congestion Avoidance: (AIMD)
CongestionWindow Size
Startup time
Time
TCP’s saw tooth pattern
Issues with additive increase
takes too long to ramp up a connection from the beginning
The entire advertised window may be reopened when a lost packet retransmitted and a single cumulative ACK is received by the sender

35. TCP “Slow Start”: To start quickly!
Maintain another variable slow start threshold (ssthresh)
Last known stable rate
If (cwnd > ssthresh)
State = congestion avoidance
Else
State = slow start
In Slow start
Increase the congestion window exponentially every RTT
Key: How is ssthresh calculated?
Every ACK reception
w = w + 1
w = cwnd in segments
Every ACK reception
cwnd = cwnd + MSS
cwnd in bytes

36. TCP: Congestion Detection and Retransmit
Loss of packet indicates congestion
Timer Timeouts (No ACK)
Set according to Jacobson/Karels algorithm
On timer timeout
ssthresh = max(2*MSS, effwin/2); cwnd = MSS
Notice this will cause TCP to go into slow start
Issue: takes a long time to detect a packet loss
Affects throughput
Any other quicker way of detecting a packet loss?

37. Fast Retransmit
Observation: A series of duplicate ACKs might mean a packet loss
Solution
Every time receiver receives a packet (out-of-order), sends a duplicate ACK
Sender retransmit the missing packet after it receives some number of duplicate ACKs (e.g. 3 duplicate ACKs)
Fast Retransmit does not replaces timeouts
Issue: Reduces latency (early retransmit) but still incurs loss in throughput (slow start after packet loss )
PKT 1
PKT 2
ACK 1
PKT 3
ACK 2
PKT 4
ACK 2
PKT 5
PKT 6
ACK 2
ACK 2
PKT 3
Retran
ACK 6

38. Fast Recovery
Transmit a packet for every ACK received till the retransmitted packet is ACK
ssthresh= (2*MSS, cwdn/2); cwnd = sshthred + 3
On every ACK will the ACK of retransmitted packet
cwnd = cwnd + 1
On reception of ACK of retransmitted packet
Start congestion avoidance instead of slow start
cwnd = ssthresh

39. Putting it all together (TCP Reno)

40. Homework
5.13
5.16
5.28
5.34
5.39
Due 4/16

41. Bonus Question
Can a TCP receiver fool a TCP sender to increase its congestion window super linearly?
Ponder: We studied that TCP increases the window size linearly during congestion avoidance. Is the rate of increase of the congestion window constant? If not, what could be the reasons?