qos aspects in an ipv6 domain - 6net

Quality of Service Aspects in an IPv6 Domain

SPEC

TS 2

004


Authors: Ch. Bouras, A. Gkamas, D.Primpas, K. Stamos

Research Academic Computer Technology Institute, Greece

University of Patras, Computer Engineering and Informatics Department, Greece

http://ru6.cti.gr


SPEC

TS 2

004

QoS techniques— IntServ

— absolute guarantees via resource reservations across the paths (RSVP)

— quite complicated operation— inserts significant network overhead

— DiffServ— classifies all the network traffic into classes — 2 different types (per hop behaviours):

• expedited forwarding (EF): aims at providing QoS for the class by minimizing jitter and is generally focused on providing stricter guarantees

• assured forwarding (AF): inserts at most 4 classes with at most 3 levels of dropping packets


SPEC

TS 2

004

QoS and IPv6— IPv6: New Internet Protocol

— 2128 addresses— other improvements

— QoS mechanisms that are currently supported for IPv6 in most implementations are fewer (or different) compared to IPv4

— RFC 3697 (Flow Label specification)

— The whole network’s behaviour is different

— QoS services should be designed and evaluated again


SPEC

TS 2

004

6NET network

ATHENSCisco 7206

THESSALONIKI

Cisco 7206

NTUACisco 7206

3Mbit ATM PVC

Gigabit Ethernet

to Munich

ATHENSGSR 12016

POS

6NET

local CTI network

Cisco 3640

CTI-PATRACisco 7206

1Mbit ATM PVC

10Mbs

— Greek part of the network

— CTI network:— Cisco router 7206— Cisco router 3640— 2 network switches, various pc— CISCO IOS 12.2(13)T


SPEC

TS 2

004

Goals

— Test an EF based service for real time applications— Investigate classification mechanism— Investigate prioritization mechanism— Investigate policing mechanism— Test all the mechanism under different traffic loads

— Test the WRED mechanism on the background traffic— Investigate mechanism’s operation— Investigate its impact on QoS service


SPEC

TS 2

004

Experimental Procedure— Traffic generated with Iperf traffic generator

— IPv6 UDP traffic• Periodic UDP traffic with specific bandwidth

— IPv6 TCP traffic• Try to sent with the fastest rate possible

— Real time traffic— IPv6 traffic created by OpenPhone (videoconference traffic using

OpenH323 library)

— Investigation of network’s performance— Congested when traffic load is up to 8Mb (10Mb link)


SPEC

TS 2

004

Experiments (network’s behavior)average jitter

0123

8 9 10 11 12

traffic load (Mb)

aver

age

jitte

r (m

s)

Series1

packet loss

0

10

20

30

8 9 10 11 12

traffic load (Mb)

pack

et lo

ss (%

)

packet loss


SPEC

TS 2

004

Experiments on EF based service— Enabled classification mechanism (using IPv6 access lists)

— Enabled prioritization mechanism (using CBWFQ, the priority mechanism)— It uses Low latency Queue for the classified traffic

— Generated traffic— Background

• TCP and UDP on various rates by Iperf

— Foreground • UDP generated by Iperf (250Kbps or 500Kbps)


SPEC

TS 2

004

Experimental results

packet loss

0

10

20

30

40

8 9 10 12

traffic load (Mb)

pack

et lo

ss (%

)

foreground traffic background traffic

average jitter

0123456

8 9 10 12

traffic load (Mb)av

erag

e jit

ter (

ms)

foreground traffic background traffic


SPEC

TS 2

004

Testing the EF based QoS service— The packet loss graphic displays efficient operation

— The graphic is created with results only for UDP traffic— For results with TCP and UDP background traffic are similar

— The jitter is significantly less on foreground traffic — Foreground traffic uses longer path to the destination (crosses

CTI’s production network and is calculated between the 2 ends)— If we measure it on the same path with the background’s traffic it

is very low


SPEC

TS 2

004

Testing the upper bound of prioritization mechanism

— The CBWFQ mechanism (priority command) had been configured to use only 20% of the bandwidth of the link

— We tried to overload the prioritization mechanism to investigate its performance

— We used UDP traffic (background and foreground), increasing the foreground each time

— The background traffic was 8Mb

Packet loss

0

5

10

15

0,5 1 2,5 2 2,5

traffic load (Mb)

pack

et lo

ss (%

)

Packet loss


SPEC

TS 2

004

Testing the EF based service with real time traffic

— Performed tests with real time traffic (by OpenH323)— Background traffic

• Mix of TCP and UDP traffic generated by Iperf— Foreground traffic

• Real time traffic generated by openphone (on testing scenario)• Real time traffic generated by openphone (on testing scenario) and

additionally UDP traffic generated by Iperf (300Kbps)

— We want to check:— Throughput of foreground traffic and of TCP’s background traffic— Quality of videoconference data


SPEC

TS 2

004

Results with real time data (scenario 1)foreground throughput

01000020000300004000050000

time

(s)

165,

6384

93

169,

5049

77

173,

5295

85

177,

8822

1

182,

2725

34

186,

8656

04

191,

4829

02

196,

4401

81

202,

2379

37

206,

2088

09

211,

9927

91

216,

9017

38

221,

1445

37

225,

0937

07

229,

2917

23

234,

0321

67

240,

1133

86

time (se c)

Thro

ughp

ut (b

ytes

/sec

) foreground throughput — Videoconference:— excellent quality — Few packet losses— Average throughput 300Kbps

— Background traffic— UDP: tries to earn bandwidth

from the remaining— TCP: adjusts its rate to the

remaining bandwidth

TCP throughput

0200000400000600000800000

10000001200000

time(

sec)

36,9

7685

3

43,9

1592

51,6

7230

7

59,3

1758

5

67,0

7517

7

75,3

7916

83,3

0372

9

91,3

0210

9

98,8

3734

2

107,

0068

9

114,

8061

4

123,

0755

2

130,

6252

9

138,

6041

1

146,

7928

1

time (sec)

thro

ughp

ut

(byt

es/s

ec)

TCP throughput


SPEC

TS 2

004

Results with real time data (scenario 2)— Foreground traffic

— Videoconference:• excellent quality • Few packet losses• Average throughput 300Kbps

— Additional UDP traffic (300Kbps)

— Background traffic— UDP: tries to earn bandwidth

from the remaining— TCP: adjusts its rate to the

remaining bandwidth

foreground throughput

020000400006000080000

100000120000

time

(s)

213,

9685

11

221,

3305

228,

4802

14

235,

7009

15

242,

4929

35

249,

3702

24

256,

2569

89

263,

0107

66

270,

0517

08

276,

9703

26

284,

1177

04

292,

0095

13

300,

6347

42

308,

2500

56

317,

0076

06

325,

9143

75

336,

7020

93time (sec)

thro

ughp

ut (b

ytes

/sec

) foreground throughput

TCP throughput

0200000400000600000800000

time

(s)

26,5

483

32,8

449

39,3

492

45,6

464

51,5

649

58,6

735

65,2

159

71,1

601

77,7

769

84,4

765

90,3

775

96,9

214

102,

874

109,

924

115,

906

122,

140

128,

406

134,

321

140,

489

time (sec)

thro

ughp

ut (b

ytes

/sec

)

TCP throughput


SPEC

TS 2

004

Investigation of WRED mechanism— WRED mechanism

— Min threshold, max threshold, dropping possibility— Investigate its impact on foreground traffic— Investigate its impact on background traffic

— Performed 2 testing scenarios— 1st scenario:

• Minthreshold = 30, maxthreshold = 50, dropping possibility = 10%, max queue size = 75 packets

— 2nd scenario:• Minthreshold = 55, maxthreshold = 75, dropping possibility = 10%,

max queue size = 75 packets


SPEC

TS 2

004

Results for WRED (scenario 1)— Foreground traffic

— Real time data (OpenH323) & additional UDP traffic (700Kbps)

— Excellent quality of videoconference

— Background traffic— UDP traffic had many packet

losses (2%)— TCP throughput was also reduced

compared to previous experiments

TCP throughput

0200000400000600000800000

10000001200000

time

(s)

11,9

4679

823

,932

848

38,4

2993

152

,801

109

67,6

2517

182

,577

796

,954

384

112,

5352

9212

6,88

0199

141,

6963

515

7,39

2082

171,

1629

5918

5,19

343

198,

8364

3121

4,46

7592

229,

6113

92

time (sec)th

roug

hput

(byt

es/s

ec)

TCP throughput


SPEC

TS 2

004

Results for WRED (scenario 2)— Foreground traffic

— Real time data (OpenH323) & additional UDP traffic (700Kbps)

— Excellent quality of videoconference

— Background traffic— UDP traffic had less packet losses

(0.90%)— TCP straggled less

— No significant impact on the foreground traffic

throughput

0200000400000600000800000

10000001200000

time

(s)

15,4

5425

526

,319

967

39,5

8291

450

,246

195

63,2

1058

478

,567

228

93,1

3155

210

8,07

5704

121,

4209

2813

6,27

3041

151,

0166

9716

4,38

5322

179,

2781

5819

3,65

9296

208,

6780

1122

3,47

5609

time (sec)th

roug

hput

(byt

es/s

ec) throughput


SPEC

TS 2

004

Overall - Conclusions— Our contribution:

— Configured and tested a QoS service for real time applications in IPv6 networks• Classification• Queue management: CBWFQ, the priority method (low latency queue)• Measured: average throughput, packet loss, jitter

— The service was tested with real time traffic and produced very good quality on videoconference (almost zero packet loss, low jitter)

— Investigation of WRED mechanism• Better performance if thresholds approach the max queue size


SPEC

TS 2

004

Future Work— Also test policing mechanism on the above QoS service

— Investigate the proper configuration of policing profile for real time data

— Test WRED mechanism when foreground traffic approaches the upper bound of bandwidth of the priority command

— Investigate the bandwidth command of CBWFQ and compare it with priority

— Extend the tests using bigger network topologies (more hops)

— Test additional QoS features that will perhaps be supported for IPv6 on future network devices and software


SPEC

TS 2

004

Thank you

Email Info:Christos Bouras ([email protected])Apostolos Gkamas ([email protected])Dimitris Primpas ([email protected])Kostas Stamos ([email protected])

mailto:[email protected]






qos aspects in an ipv6 domain - 6net

Documents