1

Traffic Sensitive Quality of Service Controller

Masters Thesis

Submitted by :Abhishek Kumar

Advisors: Prof Mark Claypool Prof Robert Kinicki

Reader: Prof Craig Wills

2

Outline

• Introduction

• Our Approach

• Quality Metrics

• TSQ Mechanism

• Evaluation

• Conclusions and Future Work

3

Spectrum of QoS Requirements of Applications

Interactive Voice Application

File Download Streaming Video

Interactive video.

Delay Sensitivity

Th

rough

pu

t Sen

sitivity

Web Browsing

GamingElectronic Mail

4

Router Support for QoS requirements

• Network congestion causes build-up at router queues, leading to high queuing delays and drops, causing loss of quality for applications.

• Reduction in the router queuing delays will provide better quality to delay sensitive applications.

• Lower drops and hence higher throughput will provide better quality to throughput sensitive applications.

• Router can thus provide QoS to applications by treating the incoming packets differently.

5

Related Work• IntServ [S.Shenker et al]: Provides per flow QoS guarantees, but

requires per-flow state information, hence difficult to scale.

• Class Based Approaches:– DiffServ [Heinanen et al, 99][Jacobson et al, 99]: Provides differentiated

service to different classes, but very complex mechanism requiring traffic monitors, classifiers and other overhead.

– CBT [Paris]: Provides class based bandwidth guarantees, but limits all Multimedia traffic to same QoS.

• ABE [Hurley et al, 2001]: Provides low queuing delays to delay-sensitive traffic, but provides only two possible traffic classification: delay-sensitive or throughput-sensitive.

6

Outline

• Introduction

• Our Approach

• Quality Metrics

• TSQ Mechanism

• Evaluation

• Conclusions and Future Work

7

Our Approach• We present the Traffic Sensitive QoS Controller (TSQ).

• TSQ can be applied on top of many existing AQM techniques.

• Applications mark each packet with a delay hint. The delay hint is a measure of an application’s sensitivity to delay.

• In our current implementation delay hints can vary from 1 to 16, where 1 means highly delay sensitive and 16 means not delay sensitive.

• The delay hints are inserted in the IP header.

8

Approach

• TSQ uses “cut-in-line” mechanism to insert packets with low delay hints towards the front of the queue.

• Packets from throughput sensitive applications are inserted at the end of the queue.

• Packets which are “cut-in-line” are dropped with a higher probability, thus preventing unfair treatment to throughput sensitive flows.

9

Relation to RED-Boston

• RED-Boston [Phirke 2002] mechanism uses delay hints and “cut-in-line” to improve the ARED AQM to provide QoS to delay-sensitive applications.

• The contribution of our approach over RED-Boston is as follows:

– Definition of new Quality Metrics for applications based on delay and throughput. We derive these metrics for 3 typical Internet applications.

– Formally define relationship between queuing delay decrease and drop probability increase for TCP “fairness”.

– Decoupling of QoS controller from AQM. TSQ can be implemented in conjunction with most existing AQM. We implement it on top of PI-controller.

10

Outline

• Introduction

• Our Approach

• Quality Metrics

• TSQ Mechanism

• Evaluation

• Conclusions and Future Work

11

Quality Metrics

• Quality of Internet Applications depends on two factors:– Delay (Delay Quality)– Throughput (Throughput Quality)

• Overall Quality of the applications is the minimum of the two qualities– Quality = min(Delay Quality, Throughput Quality)

• The quality is normalized between 0 and 1, where 1 indicates best possible quality and 0 indicates no quality at all.

• Other quality metrics can be used and TSQ can remain the same.

12

Excellent Quality Good Quality

Bad Quality

Interactive Audio Delay Quality Refs [Act02][IKK93]

Excellent Quality

Good QualityBad Quality

13

Interactive Audio Throughput QualityRefs[Cor98]

14

File Transfer Delay Quality

15

File Transfer Throughput Quality

16

Outline

• Introduction

• Our Approach

• Quality Metrics

• TSQ Mechanism

• Evaluation

• Conclusions and Future Work

17

TSQ Mechanism

AQM

Packet queue

10 Mbps

10 Mbps

5 Mbps

q

q’=

TSQ

(hint)

q’p +

p’

=

+ q+Rate

+

18

TSQ Mechanism

• On receiving each packet, the router calculates a weight..

w = (d x td)/2N + ta

• d = delay hint

• td = drain time

• N = number of bits used for delay hints

• ta = time of arrival of packet

• Lower delay hint leads to lower weight.

• The time of arrival (ta) prevents starvation.

19

• The underlying AQM has a drop probability (p) which is uniformly applied to all incoming packets.

• Unfair advantage to delay sensitive applications must be prevented. Hence drop probability is increased as follows

p’ = ((l+q)2 x p)/(l+q’)2

• l = one-way delay

• q = instantaneous queue size

• q’ = new queue position

• p = drop probability calculated by underlying AQM.

• Packets which “cut-in-line” more, will have a higher drop probability.

20

Pseudo CodeOn each received pkt:

//Calculate drain time

td = q/C

//Calculate packet weight

w = (d x td)/2n + ta

//Determine packet position in the queue

q’ = weightedInsert(w, pkt)

//Calculate new Drop probability

p’ = ((l + q)2 x p ) / (l +q’)2

//Generate Random Number

r = uniform[0,1]

If (r <= p’) then

drop(pkt)

Else

insertPacket(q’,pkt)

21

Outline

• Introduction

• Our Approach

• Quality Metrics

• TSQ Mechanism

• Evaluation

• Conclusions and Future Work

22

Evaluation

• Evaluate TSQ with PI-controller as the underlying AQM.

• PI-controller tries to maintain the queue size around a pre-set reference (qref).

• It provides a drop probability p, which is uniformly applied to all incoming packets. Drop probability is calculated as:– p = a x (q –qref) – b x (qold – qref) + pold

– pold = p– qold = q

• Simulations were conducted over the Network Simulator (ns-2), which already has PI-controller module present.

23

Set of Experiments• Impact of TSQ on the quality of a single Interactive

Audio flow.

• Impact of TSQ on the quality of a single Interactive Video flow.

• Compare performance of TSQ, against PI without TSQ, over varying traffic mixes.

• Measure the impact of unresponsive flows on TSQ.

24

Network TopologyS1

S2

SN-1

SN

Queue Size

PI, PI+TSQAQM

800 packets

qref 200 packets

R1

50 Mbps, 50 ms

D1

D2

DN-1

DN

R2

50 Mbps, 50 ms

B Mbps

25

Simulation Specifics

• PI parameters: a = 0.00001822, b = 0.00001816, w = 170 Hz, qref = 200 packets, qmax = 800 packets.

• Average Packet size = 1000 bytes.

• All experiments run for 100 seconds.

• TSQ parameters: l = 40 ms. This is the one-way delay parameter and is a constant.

26

Experiment 1: Interactive Audio Quality

Setup:• Bottle-neck Link Bandwidth = 15 Mbps.

• 100 sources and 100 destinations. One-way propagation delay is 150 ms.

• 99 TCP based file transfer flows using delay hint = 16.

• 1 TCP-friendly CBR source sending at 128 Kbps, to simulate audio flow with varying delay hints.

27

Analysis

• Low median queuing delay for lower delay hint.

• Less variation in queuing delay at lower delay hints.

28

Analysis

• Throughput measured every RTT (300 ms).

• Median throughput low for lower delay hints.

29

Analysis

• Delay Quality increases as delay hints decrease.

• Throughput Quality decreases as delay hints decrease.

30

Overall Quality

Analysis

• Overall quality is minimum of delay and throughput quality.

• Maximum quality occurs when delay hint is 6.

31

Experiment 2: Interactive Video Quality

Experimental Setup:

• Bottleneck link Bandwidth = 4 Mbps.

• 20 sources and 20 destinations. One-way delay is 150 ms.

• 19 TCP-based file transfer flows with delay hint 16.

• 1 TCP-friendly CBR source with varying delay hints, transmitting at 500 Kbps, to simulate an H.323 videoconference.

32

Analysis

• Low queuing delay with low variance for lower delay hints.

33

Analysis

• Throughput decreases as hints decrease.

• Decrease in throughput is not very significant.

34

• Delay quality improves significantly with decrease in delay hints.

• Throughput quality decreases slightly with decrease in delay hints.

Analysis

35

Analysis

• Best quality occurs at delay hint = 6.

36

Experiment 3: Performance of TSQ over varying traffic mix.

Experimental Setup:

• Bottleneck link Bandwidth = 15 Mbps.

• 100 sources and 100 destinations. One-way propagation delay = 150 ms.

• We vary the traffic mix (99 file transfer, 1 audio; 75 file transfer, 25 audio; 50 file transfer,50 audio; 25 file transfer, 75 audio).

• File transfer flows use delay hint of 16.

• Audio flows use delay hint of 6.

37

• Normalized Audio Quality always greater than 1.

• Normalized FTP Quality always greater than or equal to 1.

Analysis

38

Evaluation of TSQ with Unresponsive Flows

Experiment 1: Setup

• Bottleneck link bandwidth = 15 Mbps.

• 99 TCP based file transfer flows with delay hint 16.

• 1 UDP based (unresponsive) audio flow transmitting at 600 Kbps (above its fair share), using different delay hints.

39

Analysis

• Normalized FTP throughput is always greater than 1.

• Unresponsive flows do not gain any extra advantage due to TSQ.

40

Unresponsive Flows

Experiment 2: Setup

• 100 sources and 100 destinations. One-way propagation delay = 150 ms.

• Two types of traffic. TCP-based file transfer and UDP-based unresponsive CBR (audio) transmitting at 600 Kbps.

• We vary the traffic mix (99 file transfer, 1 audio; 75 file transfer, 25 audio; 50 file transfer,50 audio; 25 file transfer, 75 audio).

• File transfer flows use delay hint of 16.

• Unresponsive audio flows use delay hint of 6.

41

Analysis

• Normalized Audio and file transfer quality is always greater or equal to 1.

• Presence of large number of unresponsive flows does not hurt TSQ.

42

Outline

• Introduction

• Our Approach

• Quality Metrics

• TSQ Mechanism

• Evaluation

• Conclusions and Future Work

43

Conclusions

• TSQ provides a per-packet QoS to Internet Applications.

• It is a best-effort service, without any guarantees, but has low overhead. Current implementation uses only 4 IP header bits.

• It prevents flows from getting unfair advantage, by maintaining a trade-off between their delay and throughput.

• Unresponsive flows do not gain any extra advantage due to TSQ.

44

Future Work.• Research the correct number of bits to be used for

representing delay hints. [RFC 2474] suggests the use of ToS for delay hints. It is a 8-bit field and the RFC defines 6 out of the 8 bits to be used for Per-hop behavior.

• Investigate and produce quality metrics for other Internet applications.

• Build applications that can dynamically change their delay hints, thus getting maximum advantage from TSQ.