1 / 44

Traffic Sensitive Quality of Service Controller

Traffic Sensitive Quality of Service Controller. Masters Thesis Submitted by :Abhishek Kumar Advisors: Prof Mark Claypool Prof Robert Kinicki Reader: Prof Craig Wills. Outline. Introduction Our Approach Quality Metrics TSQ Mechanism Evaluation

carnig
Télécharger la présentation

Traffic Sensitive Quality of Service Controller

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 Throughput Sensitivity File Download Streaming Video Web Browsing Interactive video. Interactive Voice Application Electronic Mail Gaming DelaySensitivity

  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. Interactive Audio Delay Quality Refs [Act02][IKK93] Excellent Quality Excellent Quality Good Quality Good Quality Bad Quality Bad 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. + Rate + q TSQ Mechanism AQM 10 Mbps + q (hint) = q’ q’ TSQ p + = 5 Mbps p’ Packet queue 10 Mbps

  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 Code On 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. PI, PI+TSQ AQM Queue Size 800 packets qref 200 packets Network Topology S1 D1 50 Mbps, 50 ms S2 50 Mbps, 50 ms D2 R1 R2 B Mbps SN-1 DN-1 DN SN

  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. Analysis Overall Quality • 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. Analysis • Delay quality improves significantly with decrease in delay hints. • Throughput quality decreases slightly with decrease in delay hints.

  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. Analysis • Normalized Audio Quality always greater than 1. • Normalized FTP Quality always greater than or equal to 1.

  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.

More Related