View
219
Download
1
Tags:
Embed Size (px)
Citation preview
Designing Networks with Little or No Buffers
orCan Gulliver Survive in Lilliput?
Yashar GanjaliHigh Performance Networking GroupStanford University
[email protected]://www.stanford.edu/~yganjali
Joint work with Prof. Ashish Goel, Prof. Nick McKeown, Prof. Tim Roughgarden
October 21, 2004 - SNRC
October 21, 2004 - SNRC 2
MotivationNetworks with Little or No
Buffers Problem
Internet traffic is doubled every year Disparity between traffic and router growth
(space, power, cost) Possible Solution
All-Optical Networking Consequences
Large capacity large traffic Little or no buffers Gulliver wakes up in Lilliput!
October 21, 2004 - SNRC 3
Why do we need buffers? How large are buffers today? How small can buffers be? Summary and conclusions
Outline
October 21, 2004 - SNRC 4
Why do we need buffers? Pathological example Contention Congestion
How large are buffers today? How small can buffers be? Summary and conclusions
Outline
October 21, 2004 - SNRC 5
Pathological Example
If S1 sends a packet at time t, S2 cannot send any packets at time t, and t+1.
To achieve 100% throughput we need at least one unit of buffering.
1 2
S1
S2
D3 4
Flow 1: S1 D; Load = 50%
Flow 2: S2 D; Load = 50%
October 21, 2004 - SNRC 6
Why do we need buffers?
Internet traffic is bursty in nature Starting time Flow length variations Rate changes over time
We need buffers to compensate momentary over-subscriptions Short-term: Contention Long-term: Congestion
October 21, 2004 - SNRC 7
Contention Even when links are under-subscribed
contention occurs due to stochastic collision of packets.
October 21, 2004 - SNRC 8
Congestion
Internet uses distributed congestion control.
Links are temporarily over-subscribed.
TCP needs buffers to work.
October 21, 2004 - SNRC 9
Rule for adjusting W If an ACK is received:W ← W+1/W If a packet is lost: W ← W/2
Congestion
Only W packets may be outstanding
October 21, 2004 - SNRC 10
Congestion
Rule for adjusting W If an ACK is received:W ← W+1/W If a packet is lost: W ← W/2
Source Dest
maxW
2maxW
t
Window size
Only W packets may be outstanding
October 21, 2004 - SNRC 11
Why do we need buffers? How large are buffers today?
Congestion control Contention resolution
How small can buffers be? Summary and conclusions
Outline
October 21, 2004 - SNRC 12
Universally applied rule-of-thumb: A router needs a buffer size:• 2T is the two-way propagation delay• C is capacity of bottleneck link
The buffer needed for contention resolution is dominated by this.
Router Buffer Needed for Congestion Control
CTB 2
CRouterSource Destination
2T
October 21, 2004 - SNRC 13
Example
Link capacity 40Gbps Two way propagation delay 100ms Required buffer size 500MB
2,000,000 packets Hard to implement even in
electronics
October 21, 2004 - SNRC 14
Why do we need buffers? How large are buffers today? How small can buffers be?
Congestion control• Aggregate flows• No buffering
Contention resolution• Scheduling• Load balancing in time and space
Summary and conclusions
Outline
October 21, 2004 - SNRC 15
Buffer Size in the Core
ProbabilityDistribution
B
0
Buffer Size
W
October 21, 2004 - SNRC 16
The rule of thumb is true for one flow.
Thousands of flows in the core of the Internet.
Required buffer is instead of n is the number of flows [Appenzeller, Keslassy, McKeown 2004]
Required buffer: 20,000 packets Much less than 2,000,000 packets Still not feasible in optics
Required Buffer Size
CT 2n
CT 2
October 21, 2004 - SNRC 17
TCP with ALMOST No Buffers
Utilization of bottleneck link = 75%
October 21, 2004 - SNRC 18
TCP with Almost No Buffers
With almost no buffering and just a single flow we lose about 25% of the capacity.
Capacity is not a bottleneck anymore.
Small buffers not a major problem for congestion control.
October 21, 2004 - SNRC 19
Throughput with Little BuffersBottleneck Link Utilization vs. Number of Flows
0
0.2
0.4
0.6
0.8
1
1.2
0 100 200 300 400 500 600 700 800 900 1000
Number of Flows
Uti
liza
tio
n
Capacity: 100Mbps, Buffer size: 10 packets
October 21, 2004 - SNRC 20
Why do we need buffers? How large are buffers today? How small can buffers be?
Congestion control• Aggregate flows• No buffering
Contention resolution• Scheduling• Load balancing in time and space
Summary and conclusions
Outline
October 21, 2004 - SNRC 21
Contention Resolution
Two extreme approaches No scheduling
• Use large buffers Tight scheduling
• Inject packets according to a schedule, so that contention is minimized.
No scheduling
Tight scheduling
October 21, 2004 - SNRC 22
Exact Schedule
Hard to find in general Must be distributed Exact measurements of flows needed Extreme synchronization required
October 21, 2004 - SNRC 23
Randomization
Randomization Randomly delay packet at injection time
• Imitate a Poisson process Reshape traffic at the core
• Keep Poisson
No scheduling
Tight scheduling
???Randomization
October 21, 2004 - SNRC 24
Randomization (cont’d)
21 3 4 5 6 7
21 3 4 5
Time
Input #1
Input #2 6
Before randomization
41 2 3 5 6 7
21 63 4
Time
Input #1
Input #2 5
After randomization
October 21, 2004 - SNRC 25
Randomization (cont’d)
Mimic an M/M/1 queue
Under low load, queue size is small with high probability
Loss can be bounded
kkXP
EX
1
11
M/M/1
X
b
P(Q > b)Buffer B
Packet Loss
October 21, 2004 - SNRC 26
Example16 Node Network, Tree Shaped Topology, Load = 70%, Loss = 1%
October 21, 2004 - SNRC 27
Implications of Randomization
Alleviates short-term contention Simple to implement Guaranteed performance
October 21, 2004 - SNRC 28
Preliminary Results
Theorem. We can achieve constant factor throughput (roughly 70-80%) with very
small amount of loss using buffers of size O(log L), where L is the length of the
longest path in the network.
Assumption: No reactive flow control Typical value of L is 3 to 5
October 21, 2004 - SNRC 29
Why do we need buffers? How large are buffers today? How small can buffers be?
Congestion control• Aggregate flows• No buffering
Contention resolution• Scheduling• Load balancing in time and space
Summary and conclusions
Outline
October 21, 2004 - SNRC 30
Preliminary Results
Conjecture. Routers in the core of the current Internet only need buffers of
size O(log L) instead of the 2TxC.
Justification Currently maximum window size is 64 and 12
packets for Linux and Windows XP Access links are the bottleneck and limit the
flow Randomization takes care of momentary
collisions
October 21, 2004 - SNRC 31
Implications & Considerations
The required buffer size does not depend on the link capacity.
All we need is 10-20 packets worth of buffering (instead of thousands)
Need to study The interaction between randomization and
congestion control Impact of co-existing flows Emerging applications (non-TCP or modified
TCP) which allow much large windows per flow
October 21, 2004 - SNRC 32
Summary and conclusions We need buffers. To gain 100% we need relatively LARGE
buffers Not as large as the widely used rule of thumb
At the price of losing some capacity, TCP performs well even with small buffers.
We can address contention by adding randomization.
Gulliver might not have the best life in Lilliput, but he seems to be able to survive!
Many thanks to Guido Appenzeller for providing the flash animations.