Tcp congestion control topic in high speed network

1. Jennifer Rexford
Fall 2016 (TTh 3:00-4:20 in CS 105)
COS 561: Advanced Computer Networks
http://www.cs.princeton.edu/courses/archive/fall16/cos561/
TCP Congestion Control

2. Holding the Internet Together
• Distributed cooperation for resource allocation
– BGP: what end-to-end paths to take (for ~50K ASes)
– TCP: what rate to send over each path (for ~3B hosts)
2
AS 1
AS 2
AS 3
AS 4

3. What Problem Does a Protocol Solve?
• BGP path selection
– Select a path that each AS on the path is willing to use
– Adapt path selection in the presence of failures
• TCP congestion control
– Prevent congestion collapse of the Internet
– Allocate bandwidth fairly and efficiently
• But, can we be more precise?
– Define mathematically what problem is being solved
– To understand the problem and analyze the protocol
– To predict the effects of changes in the system
– To design better protocols from first principles 3

4. Fairness
4

5. Fair and Efficient Use of a Resource
• Suppose n users share a single resource
–Like the bandwidth on a single link
–E.g., 3 users sharing a 30 Gbps link
• What is a fair allocation of bandwidth?
–Suppose user demand is “elastic” (i.e., unlimited)
–Allocate each a 1/n share (e.g., 10 Gbps each)
• But, “equality” is not enough
–Which allocation is best: [5, 5, 5] or [18, 6, 6]?
–[5, 5, 5] is more “fair”, but [18, 6, 6] more efficient
–What about [5, 5, 5] vs. [22, 4, 4]? 5

6. Fair Use of a Single Resource
• What if some users have inelastic demand?
– E.g., 3 users where 1 user only wants 6 Gbps
– And the total link capacity is 30 Gbps
• Should we still do an “equal” allocation?
– E.g., [6, 6, 6]
– But that leaves 12 Gbps unused
• Should we allocate in proportion to demand?
– E.g., 1 user wants 6 Gbps, and 2 each want 20 Gbps
– Allocate [4, 13, 13]?
• Or, give the least demanding user all he wants?
– E.g., allocate [6, 12, 12]?
6

7. Max-Min Fairness
• The allocation must be “feasible”
– Total allocation should not exceed link capacity
• Protect the less fortunate
– Any attempt to increase the allocation of one user
– … necessarily decreases the allocation of another user
with equal or lower allocation
• Fully utilize a “bottlenecked” resource
– If demand exceeds capacity, the link is fully used
• Progressive filling algorithm
– Grow all rates until some users stop having demand
– Continue increasing all remaining rates till link is full
7

8. Resource Allocation Over Paths
• Maximum throughput: [30, 30, 0]
– Total throughput of 60, but user C starves
• Max-min fairness: [15, 15, 15]
– Equal allocation, but throughput of just 45
• Proportional fairness: [20, 20, 10]
– Balance trade-off between throughput and equality
– Throughput of 50, and penalize C for using 2 busy links
8
Three users A, B, and C
Two 30 Gbps links
A B
C

9. Distributed Algorithm for
Achieving Fairness
9

10. Network Utility Maximization (NUM)
• Users (i)
– Rate allocation: xi
– Utility function: U(xi)
• Network links (l)
– Link capacity: cl
– Routes: Rli=1 if link l on path i,
Rli=0 otherwise
10
maximize Si U(xi)
subject to Si Rlixi  cl
variables xi ≥ 0
xi
U(xi)

11. Network Utility and Fairness
11
x
U(x)
concave
(diminishing returns)
Alpha-fair utility
– U(x) = x1-a/(1-a) for a ≠ 1
– U(x) = log(x) for a = 1
small a
(more elastic demand)
large a
(more fair)
∞
0 1
Max
throughput
Proportional
fairness
Max-min
fairness

12. Solving NUM Problems
• Convex optimization
– Maximizing a concave objective
– Subject to convex constraints
• Benefits
– Locally optimal solution is globally optimal
– Can be solved efficiently on a centralized computer
• “Decomposable” into many smaller problems
12
maximize Si U(xi)
subject to Si Rlixi  cl
variables xi ≥ 0

13. Move Constraints to Objective
13
max Si U(xi)
subject to Si Rlixi  cl
variables xi ≥ 0
max Si U(xi) + Sl pl (cl – Si in S(l) xi)
decoupled
across sessions
coupled across
sessions
max Si [U(xi) – (Sl in L(i) pl ) xi] + Sl pl cl
decoupled
across sessions
decoupled
across links

14. Decomposition
14
User i
Link l
path cost
qi = S pl
offered link load
yl = S Rlixi
max (U(xi) – qi)
xi
pl[t] = (pl[t-1]
- b (cl – yl))+
rates xi
prices pl

15. Link Prices and Implicit Feedback
• What are the link prices pl?
– Measure of congestion
– Amount of traffic in excess of capacity
– That is, the packet loss!
• What are the path costs qi?
– Sum of the link prices pl along the path
– If loss is low, sum of link loss is roughly path loss
• No need for explicit feedback!
– User i can observe the path loss qi on path i
– Link l can observe the offered load yl on link l
15

16. Coming Back to TCP
• Reverse engineering
– TCP Reno
 Utilities are arctan(x)
 Prices are end-to-end packet loss
– TCP Vegas
 Utilities are log(x), i.e., proportional fairness
 Prices are end-to-end packet delays
• Forward engineering
– Use decomposition to design new variants of TCP
– E.g., TCP FAST
• Simplifications
– Fixed set of connections, focus on equilibrium behavior,
ignore feedback delays and queuing dynamics 16

17. TCP Congestion Control
17

18. Congestion in Drop-Tail FIFO Queue
• Access to the bandwidth: first-in first-out queue
– Packets transmitted in the order they arrive
✗
• Access to the buffer space: drop-tail queuing
– If the queue is full, drop the incoming packet

19. How it Looks to the End Host
• Delay: Packet experiences high delay
• Loss: Packet gets dropped along path
• How can TCP sender learn this?
– Delay: Round-trip time estimate
– Loss: Timeout and/or duplicate acknowledgments
– Mark: Packets marked by routers with large queues
✗

20. TCP Congestion Window
• Each sender maintains congestion window
–Max number of bytes to have in transit (not ACK’d)
• Adapting the congestion window
–Decrease upon losing a packet: backing off
–Increase upon success: optimistically exploring
–Always struggling to find right transfer rate
• Tradeoff
–Pro: avoids needing explicit network feedback
–Con: continually under- and over-shoots “right” rate

21. Additive Increase, Multiplicative Decrease
• How much to adapt?
– Additive increase: On success of last window of data,
increase window by 1 Max Segment Size (MSS)
– Multiplicative decrease: On loss of packet, divide
congestion window in half
• Much quicker to slow than speed up!
– Over-sized windows (causing loss) are much worse than
under-sized windows (causing lower throughput)
– AIMD: A necessary condition for stability of TCP

22. Leads to TCP Sawtooth Behavior
22
t
Congestion
Window
timeout
triple dup ACK
slow start

23. Receiver Window vs. Congestion Window
• Flow control
–Keep a fast sender from overwhelming slow receiver
• Congestion control
–Keep a set of senders from overloading the network
• Different concepts, but similar mechanisms
–TCP flow control: receiver window
–TCP congestion control: congestion window
–Sender TCP window =
min { congestion window, receiver window }

24. TCP Tahoe vs. TCP Reno
• Two similar versions of TCP
– TCP Tahoe (SIGCOMM’88 paper)
– TCP Reno (1990)
• TCP Tahoe
– Always repeat slow start after a loss
– Assign slow-start threshold to half of congestion window
• TCP Reno
– Repeat slow start after timeout-based loss
– Divide congestion window in half after triple dup ACK
24

25. Discussion
25