1. 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. 2 Outline Introduction Our Approach Quality Metrics TSQ Mechanism Evaluation Conclusions and Future Work

3. 3 Spectrum of QoS Requirements of Applications Interactive Voice Application File Download Streaming Video Interactive video. Delay Sensitivity Throughput Sensitivity Web Browsing Gaming Electronic Mail

4. 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. 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. 6 Outline Introduction Our Approach Quality Metrics TSQ Mechanism Evaluation Conclusions and Future Work

7. 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. 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. 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. 10 Outline Introduction Our Approach Quality Metrics TSQ Mechanism Evaluation Conclusions and Future Work

11. 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. 12 Excellent Quality Good Quality Bad Quality Interactive Audio Delay Quality Refs [Act02][IKK93] Excellent Quality Good Quality Bad Quality

13. 13 Interactive Audio Throughput Quality Refs[Cor98]

14. 14 File Transfer Delay Quality

15. 15 File Transfer Throughput Quality

16. 16 Outline Introduction Our Approach Quality Metrics TSQ Mechanism Evaluation Conclusions and Future Work

17. 17 TSQ Mechanism AQM Packet queue 10 Mbps 5 Mbps q q’ = TSQ (hint) q’ p + p’ = + q + Rate +

18. 18 TSQ Mechanism On receiving each packet, the router calculates a weight.. w = (d x t d )/2 N + t a d = delay hint t d = drain time N = number of bits used for delay hints t a = time of arrival of packet Lower delay hint leads to lower weight. The time of arrival (t a ) prevents starvation.

19. 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. 20 Pseudo Code On each received pkt: //Calculate drain time t d = q/C //Calculate packet weight w = (d x t d )/2 n + t a //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. 21 Outline Introduction Our Approach Quality Metrics TSQ Mechanism Evaluation Conclusions and Future Work

22. 22 Evaluation Evaluate TSQ with PI-controller as the underlying AQM. PI-controller tries to maintain the queue size around a pre- set reference (q ref ). It provides a drop probability p, which is uniformly applied to all incoming packets. Drop probability is calculated as: –p = a x (q –q ref ) – b x (q old – q ref ) + p old –p old = p –q old = q Simulations were conducted over the Network Simulator (ns-2), which already has PI-controller module present.

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

25. 25 Simulation Specifics PI parameters: a = 0.00001822, b = 0.00001816, w = 170 Hz, q ref = 200 packets, q max = 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. 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. 27 Analysis Low median queuing delay for lower delay hint. Less variation in queuing delay at lower delay hints.

28. 28 Analysis Throughput measured every RTT (300 ms). Median throughput low for lower delay hints.

29. 29 Analysis Delay Quality increases as delay hints decrease. Throughput Quality decreases as delay hints decrease.

30. 30 Overall Quality Analysis Overall quality is minimum of delay and throughput quality. Maximum quality occurs when delay hint is 6.

31. 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. 32 Analysis Low queuing delay with low variance for lower delay hints.

33. 33 Analysis Throughput decreases as hints decrease. Decrease in throughput is not very significant.

34. 34 Delay quality improves significantly with decrease in delay hints. Throughput quality decreases slightly with decrease in delay hints. Analysis

35. 35 Analysis Best quality occurs at delay hint = 6.

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

38. 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. 39 Analysis Normalized FTP throughput is always greater than 1. Unresponsive flows do not gain any extra advantage due to TSQ.

40. 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. 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. 42 Outline Introduction Our Approach Quality Metrics TSQ Mechanism Evaluation Conclusions and Future Work

43. 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. 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.