Traffic sensitive quality of service controller
This presentation is the property of its rightful owner.
Sponsored Links
1 / 44

Traffic Sensitive Quality of Service Controller PowerPoint PPT Presentation


  • 53 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


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

Outline

  • Introduction

  • Our Approach

  • Quality Metrics

  • TSQ Mechanism

  • Evaluation

  • Conclusions and Future Work


Spectrum of qos requirements of applications

Spectrum of QoS Requirements of Applications

Throughput Sensitivity

File Download

Streaming Video

Web Browsing

Interactive video.

Interactive Voice Application

Electronic Mail

Gaming

DelaySensitivity


Router support for qos requirements

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.


Related work

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.


Outline1

Outline

  • Introduction

  • Our Approach

  • Quality Metrics

  • TSQ Mechanism

  • Evaluation

  • Conclusions and Future Work


Our approach

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.


Approach

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.


Relation to red boston

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.


Outline2

Outline

  • Introduction

  • Our Approach

  • Quality Metrics

  • TSQ Mechanism

  • Evaluation

  • Conclusions and Future Work


Quality metrics

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.


Interactive audio delay quality refs act02 ikk93

Interactive Audio Delay Quality Refs [Act02][IKK93]

Excellent Quality

Excellent Quality

Good Quality

Good Quality

Bad Quality

Bad Quality


Interactive audio throughput quality refs cor98

Interactive Audio Throughput QualityRefs[Cor98]


File transfer delay quality

File Transfer Delay Quality


File transfer throughput quality

File Transfer Throughput Quality


Outline3

Outline

  • Introduction

  • Our Approach

  • Quality Metrics

  • TSQ Mechanism

  • Evaluation

  • Conclusions and Future Work


Tsq mechanism

+

Rate

+

q

TSQ Mechanism

AQM

10 Mbps

+

q

(hint)

=

q’

q’

TSQ

p

+

=

5 Mbps

p’

Packet queue

10 Mbps


Tsq mechanism1

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.


  • Traffic sensitive quality of service controller

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


  • Pseudo code

    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)


    Outline4

    Outline

    • Introduction

    • Our Approach

    • Quality Metrics

    • TSQ Mechanism

    • Evaluation

    • Conclusions and Future Work


    Evaluation

    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.


    Set of experiments

    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.


    Network topology

    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


    Simulation specifics

    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.


    Experiment 1 interactive audio quality

    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.


    Analysis

    Analysis

    • Low median queuing delay for lower delay hint.

    • Less variation in queuing delay at lower delay hints.


    Analysis1

    Analysis

    • Throughput measured every RTT (300 ms).

    • Median throughput low for lower delay hints.


    Analysis2

    Analysis

    • Delay Quality increases as delay hints decrease.

    • Throughput Quality decreases as delay hints decrease.


    Analysis3

    Analysis

    Overall Quality

    • Overall quality is minimum of delay and throughput quality.

    • Maximum quality occurs when delay hint is 6.


    Experiment 2 interactive video quality

    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.


    Analysis4

    Analysis

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


    Analysis5

    Analysis

    • Throughput decreases as hints decrease.

    • Decrease in throughput is not very significant.


    Analysis6

    Analysis

    • Delay quality improves significantly with decrease in delay hints.

    • Throughput quality decreases slightly with decrease in delay hints.


    Analysis7

    Analysis

    • Best quality occurs at delay hint = 6.


    Experiment 3 performance of tsq over varying traffic mix

    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.


    Analysis8

    Analysis

    • Normalized Audio Quality always greater than 1.

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


    Evaluation of tsq with unresponsive flows

    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.


    Analysis9

    Analysis

    • Normalized FTP throughput is always greater than 1.

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


    Unresponsive flows

    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.


    Analysis10

    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.


    Outline5

    Outline

    • Introduction

    • Our Approach

    • Quality Metrics

    • TSQ Mechanism

    • Evaluation

    • Conclusions and Future Work


    Conclusions

    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.


    Future work

    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.


  • Login