TCP Performance Considerations when modifying router queues for diffserv

1
TCP Performance Considerations (when modifying
router queues for diff-serv)
Presentation to ESCC, October 20, 1998
Becca L. Nitzan nitzan_at_es.net ESnet/Lawre
nce Berkeley National Laboratory
2
Testing various diff-serv components and how they
effect queuing in the routers.
WFQ Weighted Fair Queuing
Gives preference
CAR Committed Access Rate
Rate limits
DWRED Distributed Weighted Random Early Detection
Helps competing TCPs under congestion
3
Lab test
HP ATM analyzer
duplicate data
sun
sun
fast ether
fast ether
alpha
alpha
fddi
TTCP test data
fddi
4
Motivation to understand !
BAD TCP
GOOD TCP
5
Fairly normal TCP - output from tracelook (level
1)
6
Fairly normal TCP - output from tracelook (level
2)
7
TCP conversation
Data w/seq n
Send Host
Rcv Host
ACKs w/seq n
tcpdump capture run on the senders side
8
Fairly normal TCP - output from tracelook (level
3)
9
Fairly normal TCP - output from tracelook (level
4)
10
Committed Access Rate (CAR) uses a token bucket
queuing scheme.
In the router
Token Bucket
Host
To Network
Packets
11
Packets are dropped if they arrive too fast and
cant get a token to proceed
In the router
Token Bucket
Host
To Network
drops
Packets
12
Parameters can be set where the token bucket is
too small, (and/or TCP window size is too large)
In the router
Token Bucket
Host
To Network
drops
Packets
13
TCP oscillates if it has periodic packet drops,
which causes performance degradation
In the router
Token Bucket
Host
To Network
drops
Packets
14
TCP with drops - output from tracelook (level 1)
15
TCP with drops - output from tracelook (level 2)
16
TCP with drops - output from tracelook (level 3)
17
TCP with drops - output from tracelook (level 4)
18
TCP with drops - output from tracelook (level 5)
19
TCP with drops - output from tracelook (level 6)
20
Why didnt TCP back off to a steady state
??With other rate-limiting parameters,
TCPbacks off to a steady sate
Answer Not enough buffer space for the TCPs
window size, drops were continuous

21
ATM policing uses a leaky bucket variation
In the router
Host
Packets
Leaky Bucket
Leak
Regulated Flow
22
There may be more delay, but it may also be large
enough to hold a TCP congestion window
Send Host
In the router
Packets
Leaky Bucket
Leak
Regulated Flow
23
The sending TCP slows down waiting for
thereceivers ACK telling it to proceed
Leaky Bucket
Send Host
Packets
Queues have enough room for 2 times an entire
outstanding TCP congestion window
24
Suppose an entire windows worth is
in-flightbetween the sender and receiver
Leaky Bucket
Send Host
Packets
Rcv Host
1 window of packets in-flight
25
Sender wont send any more data until an ACK
comes from the receiver, resulting in slowdown
without dropping packets
Leaky Bucket
Send Host
Rcv Host
Packets
ACK is sent back once data comes in
26
Van Jacobsons Congestion Avoidance and Control
paper calls this self-clocking
Leaky Bucket
Send Host
Rcv Host
Packets
ACK is sent back once data comes in
27
Distributed Weighted Random Early Detection
(DWRED)
Router randomly drops packets based on precedence
as queues fill during load
The good news Random TCP senders back off,
which disrupts simultaneous TCP oscillations
The bad news UDPs send rate does not back off
28
DWRED
The good news According to Vern Paxson most
Internet traffic today is TCP
The bad news According to Mike Collins, more
and more video and voice will be on the
Internet that uses UDP
29
Demonstrated effective higher precedence with
Weighted Fair Queuing (WFQ), need wfq for atm PVCs
Past test used extra routers
precedence bit set here
atm interface
to atm core
sun
wan
site
wfq on output q here (non-atm)
30
Summary
Be careful configuring queues in the routers for
improved performance Consider traffic mix is
it TCP, UDP ? Watch TCP performance