1. 15-441 Computer Networking Lecture 16 – More TCP
As usual, thanks to Dave and Srini

2. Remember: TCP Flow Control
TCP is a sliding window protocol
For window size n, can send up to n bytes without receiving an acknowledgement
When the data is acknowledged then the window slides forward
Each packet advertises a window size
Indicates number of bytes the receiver has space for
Original TCP always sent entire window
Congestion control now limits this
Lecture 17: TCP & Congestion Control

3. Window Flow Control: Send Side
Sent but not acked
Not yet sent
Sent and acked
Next to be sent
Lecture 17: TCP & Congestion Control

4. Window Flow Control: Send Side
Packet Sent
Packet Received
Source Port
Dest. Port
Source Port
Dest. Port
Sequence Number
Sequence Number
Acknowledgment
Acknowledgment
HL/Flags
Window
HL/Flags
Window
D. Checksum
Urgent Pointer
D. Checksum
Urgent Pointer
Options…
Options...
App write
acknowledged
sent
to be sent
outside window
Lecture 17: TCP & Congestion Control

5. Window Flow Control: Receive Side
What should receiver do?
New
Receive buffer
Acked but not
delivered to user
Not yet
acked
window
Lecture 17: TCP & Congestion Control

6. Lecture 17: TCP & Congestion Control
TCP Persist
What happens if window is 0?
Receiver updates window when application reads data
What if this update is lost?
TCP Persist state
Sender periodically sends 1 byte packets
Receiver responds with ACK even if it can’t store the packet
Lecture 17: TCP & Congestion Control

7. Performance Considerations
The window size can be controlled by receiving application
Can change the socket buffer size from a default (e.g. 8Kbytes) to a maximum value (e.g. 64 Kbytes)
The window size field in the TCP header limits the window that the receiver can advertise
16 bits  64 KBytes
10 msec RTT  51 Mbit/second
100 msec RTT  5 Mbit/second
TCP options to get around 64KB limit  increases above limit
Lecture 17: TCP & Congestion Control

8. Lecture 17: TCP & Congestion Control
Large Windows
Delay-bandwidth product for 100ms delay
1.5Mbps: 18KB
10Mbps: 122KB
45Mbps: 549KB
100Mbps: 1.2MB
622Mbps: 7.4MB
1.2Gbps: 14.8MB
Why is this a problem?
10Mbps > max 16bit window
Scaling factor on advertised window
Specifies how many bits window must be shifted to the left
Scaling factor exchanged during connection setup
Lecture 17: TCP & Congestion Control

9. Window Scaling: Example Use of Options
“Large window” option (RFC 1323)
Negotiated by the hosts during connection establishment
Option 3 specifies the number of bits by which to shift the value in the 16 bit window field
Independently set for the two transmit directions
The scaling factor specifies bit shift of the window field in the TCP header
Scaling value of 2 translates into a factor of 4
Old TCP implementations will simply ignore the option
Definition of an option
TCP syn
SW? 3
TCP syn,ack
SW yes 3
SW? 2
TCP ack
SW yes 2
Lecture 17: TCP & Congestion Control

10. Lecture 17: TCP & Congestion Control
Silly Window Syndrome
Problem: (Clark, 1982)
If receiver advertises small increases in the receive window then the sender may waste time sending lots of small packets
Solution
Receiver must not advertise small window increases
Increase window by min(MSS,RecvBuffer/2)
Lecture 17: TCP & Congestion Control

11. TCP ACK Generation [RFC 1122, RFC 2581]
Event
In-order segment arrival,
No gaps,
Everything else already ACKed
One delayed ACK pending
Out-of-order segment arrival
Higher-than-expect seq. #
Gap detected
Arrival of segment that
partially or completely fills gap
TCP Receiver action
Delayed ACK. Wait up to 500ms
for next segment. If no next segment,
send ACK
Immediately send single
cumulative ACK
Send duplicate ACK, indicating seq. #
of next expected byte
Immediate ACK
Lecture 17: TCP & Congestion Control

12. Lecture 17: TCP & Congestion Control
Delayed Ack Impact
TCP congestion control triggered by acks
If receive half as many acks  window grows half as fast
Slow start with window = 1
Will trigger delayed ack timer
First exchange will take at least 200ms
Start with > 1 initial window
Bug in BSD, now a “feature”/standard
Lecture 17: TCP & Congestion Control

13. Lecture 17: TCP & Congestion Control
Nagel’s Algorithm
Small packet problem:
Don’t want to send a 41 byte packet for each keystroke
How long to wait for more data?
Solution:
Allow only one outstanding small (not full sized) segment that has not yet been acknowledged
Can be disabled for interactive applications
Lecture 17: TCP & Congestion Control

14. Maximum Segment Size (MSS)
Problem: what packet size should a connection use?
Exchanged at connection setup
Uses a TCP option
Typically pick MTU of local link
What all does this effect?
Efficiency
Congestion control
Retransmission
Path MTU discovery
Why should MTU match MSS?
Lecture 17: TCP & Congestion Control

15. Lecture 17: TCP & Congestion Control
Sequence Number Space
Each byte in byte stream is numbered.
32 bit value
Wraps around
Initial values selected at start up time
TCP breaks up the byte stream into packets.
Packet size is limited to the Maximum Segment Size
Each packet has a sequence number.
Indicates where it fits in the byte stream
13450
14950
16050
17550
packet 8
packet 9
packet 10
Lecture 17: TCP & Congestion Control

16. Reliability Challenges
Congestion related losses
Variable packet delays
What should the timeout be?
Reordering of packets
How to tell the difference between a delayed packet and a lost one?
Lecture 17: TCP & Congestion Control

17. TCP = Go-Back-N Variant
Sliding window with cumulative acks
Receiver can only return a single “ack” sequence number to the sender.
Acknowledges all bytes with a lower sequence number
Starting point for retransmission
Duplicate acks sent when out-of-order packet received
But: sender only retransmits a single packet.
Reason???
Only one that it knows is lost
Network is congested  shouldn’t overload it
Error control is based on byte sequences, not packets.
Retransmitted packet can be different from the original lost packet – Why?
Lecture 17: TCP & Congestion Control

18. Round-trip Time Estimation
Wait at least one RTT before retransmitting
Importance of accurate RTT estimators:
Low RTT estimate
unneeded retransmissions
High RTT estimate
poor throughput
RTT estimator must adapt to change in RTT
But not too fast, or too slow!
Spurious timeouts
“Conservation of packets” principle – never more than a window worth of packets in flight
Lecture 17: TCP & Congestion Control

19. Original TCP Round-trip Estimator
Round trip times exponentially averaged:
New RTT = a (old RTT) + (1 - a) (new sample)
Recommended value for a:
0.875 for most TCP’s
Retransmit timer set to (b * RTT), where b = 2
Every time timer expires, RTO exponentially backed-off
Not good at preventing spurious timeouts
Why?
Lecture 17: TCP & Congestion Control

20. Lecture 17: TCP & Congestion Control
RTT Sample Ambiguity A B A B
Original transmission
retransmission
Sample
RTT
ACK
RTO
Original transmission X
RTO
Sample
RTT
retransmission
ACK
Karn’s RTT Estimator
If a segment has been retransmitted:
Don’t count RTT sample on ACKs for this segment
Keep backed off time-out for next packet
Reuse RTT estimate only after one successful transmission
Lecture 17: TCP & Congestion Control

21. Jacobson’s Retransmission Timeout
Key observation:
At high loads round trip variance is high
Solution:
Base RTO on RTT and standard deviation
RTO = RTT + 4 * rttvar
new_rttvar = b * dev + (1- b) old_rttvar
Dev = linear deviation
Inappropriately named – actually smoothed linear deviation
Lecture 17: TCP & Congestion Control

22. Lecture 17: TCP & Congestion Control
Timestamp Extension
Used to improve timeout mechanism by more accurate measurement of RTT
When sending a packet, insert current time into option
4 bytes for time, 4 bytes for echo a received timestamp
Receiver echoes timestamp in ACK
Actually will echo whatever is in timestamp
Removes retransmission ambiguity
Can get RTT sample on any packet
Lecture 17: TCP & Congestion Control

23. Lecture 17: TCP & Congestion Control
Timer Granularity
Many TCP implementations set RTO in multiples of 200,500,1000ms
Why?
Avoid spurious timeouts – RTTs can vary quickly due to cross traffic
Make timers interrupts efficient
What happens for the first couple of packets?
Pick a very conservative value (seconds)
Lecture 17: TCP & Congestion Control

24. Lecture 17: TCP & Congestion Control
Fast Retransmit
What are duplicate acks (dupacks)?
Repeated acks for the same sequence
When can duplicate acks occur?
Loss
Packet re-ordering
Window update – advertisement of new flow control window
Assume re-ordering is infrequent and not of large magnitude
Use receipt of 3 or more duplicate acks as indication of loss
Don’t wait for timeout to retransmit packet
Lecture 17: TCP & Congestion Control

25. Lecture 17: TCP & Congestion Control
Fast Retransmit
Retransmission X
Duplicate Acks
Sequence No
Packets
Acks
Time
Lecture 17: TCP & Congestion Control

26. Lecture 17: TCP & Congestion Control
TCP (Reno variant) X X X
Now what? - timeout X
Sequence No
Packets
Acks
Time
Lecture 17: TCP & Congestion Control

27. Lecture 17: TCP & Congestion Control
SACK
Basic problem is that cumulative acks provide little information
Selective acknowledgement (SACK) essentially adds a bitmask of packets received
Implemented as a TCP option
Encoded as a set of received byte ranges (max of 4 ranges/often max of 3)
When to retransmit?
Still need to deal with reordering  wait for out of order by 3pkts
Lecture 17: TCP & Congestion Control

28. Lecture 17: TCP & Congestion Control
SACK X X X
Now what? – send
retransmissions as soon
as detected X
Sequence No
Packets
Acks
Time
Lecture 17: TCP & Congestion Control

29. Lecture 17: TCP & Congestion Control
Review
TCP Connection Set-Up
TCP Connection Tear-Down
Lecture 17: TCP & Congestion Control

30. Establishing Connection: Three-Way handshake
Each side notifies other of starting sequence number it will use for sending
Why not simply chose 0?
Must avoid overlap with earlier incarnation
Security issues
Each side acknowledges other’s sequence number
SYN-ACK: Acknowledge sequence number + 1
Can combine second SYN with first ACK
SYN: SeqC
ACK: SeqC+1
SYN: SeqS
ACK: SeqS+1
Client
Server
Lecture 17: TCP & Congestion Control

31. TCP Connection Setup Example
09:23: IP > : S
: (0) win <mss 1260,nop,nop,sackOK> (DF)
09:23: IP > : S
: (0) ack win 5840 <mss 1460,nop,nop,sackOK> (DF)
09:23: IP > : . ack
win (DF)
Client SYN
SeqC: Seq. # , window 65535, max. seg. 1260
Server SYN-ACK+SYN
Receive: # (= SeqC+1)
SeqS: Seq. # , window 5840, max. seg. 1460
Client SYN-ACK
Receive: # (= SeqS+1)
Lecture 17: TCP & Congestion Control

32. TCP State Diagram: Connection Setup
Client
CLOSED
Server
active OPEN
create TCB
Snd SYN
passive OPEN
CLOSE
create TCB
delete TCB
LISTEN
CLOSE
delete TCB
rcv SYN
SEND
SYN
RCVD
snd SYN ACK
snd SYN
SYN
SENT
rcv SYN
snd ACK
Rcv SYN, ACK
rcv ACK of SYN
Snd ACK
CLOSE
Send FIN
ESTAB
Lecture 17: TCP & Congestion Control

33. Tearing Down Connection
Either side can initiate tear down
Send FIN signal
“I’m not going to send any more data”
Other side can continue sending data
Half open connection
Must continue to acknowledge
Acknowledging FIN
Acknowledge last sequence number + 1 A B
FIN, SeqA
ACK, SeqA+1
Data
ACK
FIN, SeqB
ACK, SeqB+1
Lecture 17: TCP & Congestion Control

34. TCP Connection Teardown Example
09:54: IP > : F
: (0) ack win (DF)
09:54: IP > : F
: (0) ack win 5840 (DF)
09:54: IP > : . ack
win (DF)
Session
Echo client on , server on
Client FIN
SeqC:
Server ACK + FIN
Ack: (= SeqC+1)
SeqS:
Client ACK
Ack: (= SeqS+1)
Lecture 17: TCP & Congestion Control

35. State Diagram: Connection Tear-down
CLOSE
Active Close
ESTAB
send FIN
Passive Close
CLOSE
rcv FIN
send FIN
send ACK
FIN
WAIT-1
CLOSE
WAIT
rcv FIN
CLOSE
ACK
snd ACK
snd FIN
rcv FIN+ACK
FIN WAIT-2
CLOSING
LAST-ACK
snd ACK
rcv ACK of FIN
rcv ACK of FIN
TIME WAIT
CLOSED
rcv FIN
Timeout=2msl
snd ACK
delete TCB
Lecture 17: TCP & Congestion Control