1 Traffic Sensitive Quality of Service Controller Masters Thesis Submitted by :Abhishek Kumar...
-
date post
20-Dec-2015 -
Category
Documents
-
view
215 -
download
2
Transcript of 1 Traffic Sensitive Quality of Service Controller Masters Thesis Submitted by :Abhishek Kumar...
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
16
Outline
• Introduction
• Our Approach
• Quality Metrics
• TSQ Mechanism
• Evaluation
• Conclusions and Future Work
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.
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
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.