A testbed investigation of QoS mechanisms for supporting

Download Report

Transcript A testbed investigation of QoS mechanisms for supporting

A test-bed investigation of
QoS mechanisms for
supporting SLAs in IPv6
Vasilios A. Siris and Georgios Fotiadis
University of Crete and FORTH
Heraklion, Crete, Greece
[email protected]
Funded in part by GRNET, through subcontract in 6NET (IST-2001-32603)
Objectives and motivation

Investigate operation and interaction of QoS
mechanisms in IPv6 networks



These mechanisms will be used in customerprovider interface
Tuning is important for supporting Service
Level Agreements (SLAs)


Policing, shaping, queuing
Tuning each in isolation not sufficient
Do they have different performance in IPv6
compared to IPv4?
User-network interface
User/customer
Provider
policing class-based
shaping,
queuing
class-based
queuing
traffic flow
QoS mechanisms investigated

Cisco Traffic Policing




Cisco Generic Traffic Shaping - GTS
Linux Traffic Policing
Linux Traffic Shaping


Committed Access Rate – CAR not
supported in IPv6
Token Bucket Filter – TBF
Linux Class Based Queuing - CBQ
Token bucket algorithm


True token bucket (r,b)
Shaping includes a buffer
Token rate r
Token bucket
depth: b
x
Yes, x=x-L
xL?
Arriving packet:
length L

No, packet is
nonconforming
Implementation differs



Mean rate or Committed Information Rate (CIR)
Committed Burst Size (Bc)
Time interval (=Bc/CIR)
IPv6 test-bed
Linux-based router or
Cisco 7100/7200
100 Mbps
RedHat
Linux 9.0
RedHat
Linux 9.0
shaping,
class-based
queueing
policing
classbased
queueing
traffic flow


TCP traffic generated with Iperf 1.7.0 for Linux
RTT < 4 ms
Policing tests topology
Linux-based router or
Cisco 7100/7200
policing
TCP traffic

For fixed policing rate, measure aggregate
throughput for different burst sizes
(Mbps)
Throughput
Aggregate
Agg. Throughput
- Mbps
Variable policing rates (1/3)
Only Policing (Router),
Variable Policing Rate,
1 Connection - 3 Flows
50
45
40
35
30
10 Mbps
20 Mbps
25
30 Mbps
40 Mbps
20
50 Mbps
70 Mbps
15
10
5
0
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
1.8
Burst Size (Bc) - Mbits
Burst
size, Bc (Mbits)
2
2.2
2.4
2.6
2.8
Variable policing rates (2/3)


Aggregate throughput increases with
burst size, but is always < policing rate
For higher rates throughput is
proportionally smaller



Rate = 10 Mbps -> Throughput = 9.7
Rate = 70 Mbps -> Throughput = 46
Experiments for both Cisco & Linux
routers gave identical results
Variable policing rates (3/3)

Throughput versus burst size exhibits a
“knee” at Bc*, which is approximately:



If Rate < 40Mbps,
Bc* = 0.6 Mbit + 0.03sec*Rate
If Rate > 40Mbps,
Bc* = 1.5 Mbit + 0.01sec*Rate
Burst Size > RTT*Rate not sufficient!
(Mbps)
Throughput
Aggregate
Agg. Throughput
- Mbps
Variable number of flows (1/2)
Only Policing (Router),
Variable Number of Flows,
Policing Rate = 50Mbps
45
40
35
30
25
1 Flow
3 Flows
5 Flows
20
10 Flows
15
10
5
0
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
1.8
2
2.2
Burst size, Bc (Mbits)
Burst Size (Bc) - Mbits
2.4
2.6
2.8
3
3.2
Variable number of flows (2/2)



Optimum burst size (“knee” value) is
independent of the number of flows
Aggregate throughput increases with
number of flows (multiplexing)
Similar results for Cisco & Linux routers
Interaction of policing & shaping
Linux-based router
or Cisco 7100/7200
shaping
policing
TCP traffic

For fixed rate & burst size of policer and rate of
shaper, measure aggregate throughput for
different burst sizes of shaper
Throughput vs. burst size (1/4)
(Mbps)
Throughput
Aggregate
Agg. Throughput
- Mbps
Interaction of Policing and Shaping,
Variable Number of Flows,
Shaping (Router1): Rate = 50Mpbs, Buffer Limit = 1000pkts,
Policing (Router2): Rate = 50Mbps, Bc = 2Mbits.
50
45
40
1 Flow
35
3 Flows
30
5 Flows
10 Flows
25
No Shaping (1 Flow)
No Shaping (3 Flows )
20
No Shaping (5 Flows )
15
No Shaping (10 Flows )
10
Shaping at Linux
Policing at Cisco
5
0
0
0. 0. 0. 0.
2 4 6 8
1
1. 1. 1. 1.
2 4 6 8
2
2. 2. 2. 2.
2 4 6 8
3
3. 3. 3. 3.
2 4 6 8
Burst Size (Bc) - Mbits
Burst
size, Bc (Mbits)
4
4. 4. 4. 4.
2 4 6 8
5
5.
2
Throughput vs. burst size (2/4)

Appropriate shaper burst size can lead to
significant throughput increase



Low throughput for very small burst sizes


Throughput is always higher with shaping
Setting burst size of shaper = burst size of policer
not always optimal
Due to overflow at shaper’s queue
But also, very large burst size gives low
throughput

Very large burst sizes allow large bursts which lead
to multiple drops at the policer
Throughput vs. burst size (3/4)

For larger # of flows there is larger
range of burst sizes that achieve
maximum throughput
Throughput vs. burst size (4/4)
No qualitative difference when using two Linux
or Linux & Cisco routers
(Mbps)
Throughput
AggregateAgg.
Throughput - Mbps
Interaction of Policing and Shaping,
Variable Number of Flows,
Shaping (Router1): Rate = 50Mpbs, Buffer Limit = 1000pkts,
Policing (Router2): Rate = 50Mbps, Bc = 2Mbits.
60
50
1 Flow
40
3 Flows
5 Flows
10 Flows
30
No Shaping (1 Flow)
No Shaping (3 Flows )
No Shaping (5 Flows )
20
No Shaping (10 Flows )
10
0
0
0. 0. 0. 0.
2 4 6 8
1
1. 1. 1. 1.
2 4 6 8
2
2. 2. 2. 2.
2 4 6 8
3
3. 3. 3. 3.
2 4 6 8
Burst size, Bc (Mbits)
Burst Size (Bc) - Mbits
4
4. 4. 4. 4.
2 4 6 8
5
5.
2
Shaping at Linux
Policing at Linux
Throughput vs. shaping rate (1/2)
(Mbps)
Aggregate
Agg.Throughput
Throughput - Mbps
Policing rate
Shaping at Linux
Policing at Cisco
Interaction of Policing and Shaping,
Variable Number of Flows,
Shaping (Router1): Bc = 2Mbits, Buffer Limit = 1000pkts,
Policing (Router2): Rate = 50Mbps, Bc = 2Mbits.
50
45
40
35
1 Flow
30
3 Flows
5 Flows
25
No Shaping (1 Flow)
No Shaping (3 Flows)
20
No Shaping (5 Flows)
15
10
5
0
44
46
48
50
52
54
Shaping Rate - Mbps
56
Shaping Rate (Mbps)
58
60
62
Throughput vs. shaping rate (2/2)


Throughput maximum for shaping rate a
little higher than policing rate
Very high shaping rates leads to
throughput degradation, due to bursts
that are allowed by the shaper
Delay jitter tests (1/3)

Policing/Shaping tests showed there is
a range of shaper burst sizes for which
throughput is maximized
Which burst size is best?

Answer: consider delay

Delay jitter tests (2/3)
(Mbps)
Throughput
AggregateAverage
Jitter - ms
Interaction of Policing and Shaping,
Shaping (Router1): Rate = 50Mpbs, Buffer Limit = 1000pkts,
Policing (Router2): Rate = 50Mbps, Bc = 2Mbits.
1.2
1
0.8
0.6
1 Flow
0.4
0.2
0
0
0.2
0.4
0.6
0.8
1
1.2
Burst Size (Bc) - Mbits
Burst Size,
Bc (Mbit)
1.4
1.6
1.8
2
Delay jitter tests (3/3)


Jitter decreases when burst size
increases
Optimal burst size is one for which
delay jitter is smallest, but is in the
range of values that maximize
throughput
Interaction of Policing and
Class Base Queuing
Linux-based router or
Cisco 7100/7200
class-based
queuing
policing
TCP traffic

For fixed rate & burst size of policer and rate of
CBQ, measure aggregate throughput for different
maxburst values
Variable maxburst at CBQ (1/2)
(Mbps)
Throughput
Aggregate Throughput
- Mbps
Interaction of CBQ and Policing,
CBQ (Router1): Rate = 50Mpbs
Policing (Router2): Rate = 50Mbps, Bc = 2Mbits,
CBQ at Linux
Policing at Cisco
60
50
40
30
5 Flows
20
10
0
0
50
100
150
Maxburst - packets
maxburst
(packets)
200
250
Variable maxburst at CBQ (2/2)



Maximum throughput achieved with
appropriate maxburst value
Low throughput for small maxburst
Large maxburst values do not result in
throughput degradation


maxburst has different effect than burst
size in shaping
CBQ performs traffic smoothing
Conclusions and outlook


Interaction of QoS mechanisms is important
for effectively supporting SLAs
In the presence of policing, shaping can
increase aggregate throughput

Must appropriately set shaping parameters

Tuning of parameters should consider
throughput & delay
Similar behavior with Cisco/Linux, IPv6/IPv4

Further research directions:



Experiments in wide area (larger RTT)
Experiments in wireless networks
A test-bed investigation of
QoS mechanisms for
supporting SLAs in IPv6
Vasilios A. Siris and Georgios Fotiadis
University of Crete and FORTH
Heraklion, Crete, Greece
[email protected]
Funded in part by GRNET, through subcontract in 6NET (IST-2001-32603)