1. Transport Layer ECE544: Communication Networks-II, Spring 2013
Tam Vu
WINLAB, Dept. of Computer Science
Rutgers University
Includes teaching materials from, L. Peterson, Sumathi Gopal and Sumit Rangwala, D. Raychaudhuri, Mike Freedman

2. IP Protocol Stack: Key Abstractions
Application
Best-effort local packet delivery
Best-effort global packet delivery
Reliable streams
Applications
Messages
Transport
Network
Link
Problem: Network Layer (IP) provides only best-effort communication services

3. Applications requirements vs. IP layer limitations
Guarantee message delivery
Network may drop messages.
Deliver messages in the same order they are sent
Messages may be reordered in networks and incurs a long delay.
Delivers at most one copy of each message
Messages may duplicate in networks.
Support arbitrarily large message
Network may limit message size.
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

4. IP Protocol Stack: Key Abstractions
Application
Best-effort local packet delivery
Best-effort global packet delivery
Reliable streams
Applications
Messages
Transport
Network
Link
Transport layer:
Provide applications with good abstractions
Without support or feedback from the network
Is the lowest layer in the network stack that is an end-to-end protocol

5. Transport Protocols Logical communication between processes
Sender divides a message into segments
Receiver reassembles segments into message
Transport services
(De)multiplexing packets
Detecting corrupted data
Optionally: reliable delivery, flow control, …

6. Two Basic Transport Features
Demultiplexing: port numbers
Error detection: checksums
Server host
Client host
Service request for
:80
(i.e., the Web server)
Web server
(port 80)
Client OS
Echo server
(port 7) IP
payload
detect corruption 6

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

8. User Datagram Protocol (UDP)
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 ]
Lightweight communication between processes
Send and receive messages
Avoid overhead of ordered, reliable delivery
No connection setup delay, in-kernel connection state
Used by popular apps
Query/response for DNS
Real-time data in VoIP 16 31
SrcPort
DesPort
Length
Checksum
Payload

9. User Datagram Protocol (UDP): Error Detection
Service: Ensure message correctness
Issue: Packet corruption in transit
Solution
Use Checksum.
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

10. Transmitting a stream of bytes ?
Connection oriented
Explicit set-up and tear- down of TCP connection
Flow control
Prevent overflow of the receiver’s buffer space
Congestion control
Adapt to network congestion for the greater good
Stream-of-bytes service
Sends and receives a stream of bytes
Reliable, in-order delivery
Corruption: checksums
Detect loss/reordering: sequence numbers
Reliable delivery: acknowledgments and retransmissions

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

12. Starting and Ending a Connection: TCP Handshakes

13. Establishing a TCP Connection
SYN
Each host tells its Initial Sequence Number (ISN) to the other host.
SYN ACK
ACK
Data
Data
Three-way handshake to establish connection
Host A sends a SYN (open) to the host B
Host B returns a SYN acknowledgment (SYN ACK)
Host A sends an ACK to acknowledge the SYN ACK

14. TCP Header Source port Destination port Sequence number Flags: SYN FIN
RST
PSH
URG
ACK
Acknowledgment
HdrLen
Flags
Advertised window
Checksum
Urgent pointer
Options (variable)
Data

15. Step 1: A’s Initial SYN Packet
A’s port
B’s port
A’s Initial Sequence Number
Flags:
SYN
FIN
RST
PSH
URG
ACK
Acknowledgment 20
Flags
Advertised window
Checksum
Urgent pointer
Options (variable)
A tells B it wants to open a connection…

16. Step 2: B’s SYN-ACK Packet
B’s port
A’s port
B’s Initial Sequence Number
Flags:
SYN
FIN
RST
PSH
URG
ACK
A’s ISN plus 1 20
Flags
Advertised window
Checksum
Urgent pointer
Options (variable)
B tells A it accepts, and is ready to hear the next byte…
… upon receiving this packet, A can start sending data 17

17. Step 3: A’s ACK of the SYN-ACK
A’s port
B’s port
Sequence number
Flags:
SYN
FIN
RST
PSH
URG
ACK
B’s ISN plus 1 20
Flags
Advertised window
Checksum
Urgent pointer
Options (variable)
A tells B it is okay to start sending
… upon receiving this packet, B can start sending data 18

18. SYN Loss and Web Downloads
Upon sending SYN, sender sets a timer
If SYN lost, timer expires before SYN-ACK received
Sender retransmits SYN
How should the TCP sender set the timer?
No idea how far away the receiver is
Some TCPs use default of 3 or 6 seconds
Implications for web download
User gets impatient and hits reload
… Users aborts connection, initiates new socket
Essentially, forces a fast send of a new SYN! 19

19. Tearing Down the ConnectionB
ACK
SYN
SYN ACK
Data
ACK
FIN
ACK
FIN
ACK A
time
Closing (each end of) the connection
Finish (FIN) to close and receive remaining bytes
And other host sends a FIN ACK to acknowledge
Reset (RST) to close and not receive remaining bytes 20

20. Sending/Receiving the FIN Packet
Sending a FIN: close()
Process is done sending data via socket
Process invokes “close()”
Once TCP has sent all the outstanding bytes…
… then TCP sends a FIN
Receiving a FIN: EOF
Process is reading data from socket
Eventually, read call returns an EOF 21

21. Data transmission

22. 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)

23. TCP “Stream of Bytes” Service
Host A
Byte 0
Byte 1
Byte 2
Byte 3
Byte 80
Host B
Byte 0
Byte 1
Byte 2
Byte 3
Byte 80 24

24. …Emulated Using TCP “Segments”
Host A
Byte 0
Byte 1
Byte 2
Byte 3
Byte 80
Segment sent when:
Segment full (Max Segment Size),
Not full, but times out, or
“Pushed” by application
TCP Data
TCP Data
Host B
Byte 0
Byte 1
Byte 2
Byte 3
Byte 80 25

25. TCP Segment IP packet TCP packet TCP segment
IP Hdr
IP Data
TCP Hdr
TCP Data (segment)
IP packet
No bigger than Maximum Transmission Unit (MTU)
E.g., up to 1500 bytes on an Ethernet link
TCP packet
IP packet with a TCP header and data inside
TCP header is typically 20 bytes long
TCP segment
No more than Maximum Segment Size (MSS) bytes
E.g., up to 1460 consecutive bytes from the stream 26

26. Sequence Number Sequence number = 1st byte Host A Host B
ISN (initial sequence number)
Byte 81
Sequence number = 1st byte
TCP Data
TCP Data
Host B 27

27. Reliable Delivery on a Lossy Channel With Bit Errors

28. Challenges of Reliable Data Transfer
Over a perfectly reliable channel: Done
Over a channel with bit errors
Receiver detects errors and requests retransmission
Over a lossy channel with bit errors
Some data missing, others corrupted
Receiver cannot easily detect loss
Over a channel that may reorder packets
Receiver cannot easily distinguish loss vs. out-of-order 30

29. An Analogy Alice and Bob are talking
What if Alice couldn’t understand Bob?
Bob asks Alice to repeat what she said
What if Bob hasn’t heard Alice for a while?
Is Alice just being quiet? Has she lost reception?
How long should Bob just keep on talking?
Maybe Alice should periodically say “uh huh”
… or Bob should ask “Can you hear me now?” 31

30. Take-Aways from the Example
Acknowledgments from receiver
Positive: “okay” or “uh huh” or “ACK”
Negative: “please repeat that” or “NACK”
Retransmission by the sender
After not receiving an “ACK”
After receiving a “NACK”
Timeout by the sender (“stop and wait”)
Don’t wait forever without some acknowledgment 32

31. TCP Support for Reliable Delivery
Detect bit errors: checksum
Used to detect corrupted data at the receiver
…leading the receiver to drop the packet
Detect missing data: sequence number
Used to detect a gap in the stream of bytes
... and for putting the data back in order
Recover from lost data: retransmission
Sender retransmits lost or corrupted data
Two main ways to detect lost packets 33

32. TCP Acknowledgments Host A Sequence number = 1st byte
ISN (initial sequence number)
Sequence number = 1st byte
TCP Data
ACK sequence number = next expected byte
TCP Data
Host B 34

33. Automatic Repeat reQuest (ARQ)
ACK and timeouts
Receiver sends ACK when it receives packet
Sender waits for ACK and times out
Simplest ARQ protocol
Stop and wait
Send a packet, stop and wait until ACK arrives
Time
Packet
ACK
Timeout
Sender
Receiver

34. Quick TCP Math
Initial Seq No = Sender sends 4500 bytes successfully acknowledged. Next sequence number to send is:
(A) (B) (C) (D) 5002
Next 1000 byte TCP segment received. Receiver acknowledges with ACK number:
(A) (B) (C) 6001

35. Flow Control: TCP Sliding Window

36. Sliding Window: Motivation
Stop-and-wait is inefficient
Only one TCP segment is “in flight” at a time
Consider: 1.5 Mbps link with 50 ms round-trip-time (RTT)
Assume segment size of 1 KB (8 Kbits)
8 Kbits/segment at 50 msec/segment  160 Kbps
That’s 11% of the capacity of 1.5 Mbps link 39

37. Sliding Window Allow a larger amount of data “in flight”
Allow sender to get ahead of the receiver
… though not too far ahead
Sending process
Receiving process
TCP
TCP
Last byte written
Last byte read
Next byte expected
Last byte ACKed
Last byte received
Last byte sent 40

38. Receiver Buffering Receive window size
Amount that can be sent without acknowledgment
Receiver must be able to store this amount of data
Receiver tells the sender the window
Tells the sender the amount of free space left
Window Size
Data ACK’d
Outstanding
Un-ack’d data
Data OK
to send
Data not OK
to send yet 41

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

40. Optimizing Retransmissions

41. Reasons for Retransmission
Packet
Packet
Packet
Timeout
Timeout
Timeout
ACK
ACK
Packet
Packet
Packet
ACK
Timeout
Timeout
Timeout
ACK
ACK
ACK lost
DUPLICATE PACKET
Early timeout
DUPLICATE PACKETS
Packet lost

42. How Long Should Sender Wait?
Sender sets a timeout to wait for an ACK
Too short: wasted retransmissions
Too long: excessive delays when packet lost
TCP sets timeout as a function of the RTT
Expect ACK to arrive after an “round-trip time”
… plus a fudge factor to account for queuing
But, how does the sender know the RTT?
Running average of delay to receive an ACK 45

43. 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
Constant β is not good.
Assumes constant variance

44. TCP Timeout Karn/Partridge Algorithm
Whenever TCP retransmits a segment, it stops taking samples of the RTT
Only measure SampleRTT for segments that 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 )

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

46. 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”

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

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

49. 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.
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)

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

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

52. 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
cwnd = cwnd + MSS
cwnd in bytes
Every ACK reception
w = w + 1
w = cwnd in segments

53. 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?

54. 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 replace 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

55. Fast Recovery
Transmit a packet for every ACK received till the retransmitted packet is ACK’d
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

56. Homework
5.13 (3rd ed and 4th ed)
5.16
5.28
5.34
5.39
Due 4/5