Traffic sensitive quality of service controller
Download
1 / 44

Traffic Sensitive Quality of Service Controller - PowerPoint PPT Presentation


  • 93 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Traffic Sensitive Quality of Service Controller' - carnig


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





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 uniformly applied to all incoming packets.

    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 uniformly applied to all incoming packets.

    • Introduction

    • Our Approach

    • Quality Metrics

    • TSQ Mechanism

    • Evaluation

    • Conclusions and Future Work


    Evaluation
    Evaluation uniformly applied to all incoming packets.

    • 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 uniformly applied to all incoming packets.

    • 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 uniformly applied to all incoming packets.

    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 uniformly applied to all incoming packets.

    • 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 uniformly applied to all incoming packets.

    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 uniformly applied to all incoming packets.

    • Low median queuing delay for lower delay hint.

    • Less variation in queuing delay at lower delay hints.


    Analysis1
    Analysis uniformly applied to all incoming packets.

    • Throughput measured every RTT (300 ms).

    • Median throughput low for lower delay hints.


    Analysis2
    Analysis uniformly applied to all incoming packets.

    • Delay Quality increases as delay hints decrease.

    • Throughput Quality decreases as delay hints decrease.


    Analysis3
    Analysis uniformly applied to all incoming packets.

    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 uniformly applied to all incoming packets.

    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 uniformly applied to all incoming packets.

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


    Analysis5
    Analysis uniformly applied to all incoming packets.

    • Throughput decreases as hints decrease.

    • Decrease in throughput is not very significant.


    Analysis6
    Analysis uniformly applied to all incoming packets.

    • Delay quality improves significantly with decrease in delay hints.

    • Throughput quality decreases slightly with decrease in delay hints.


    Analysis7
    Analysis uniformly applied to all incoming packets.

    • 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. uniformly applied to all incoming packets.

    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 uniformly applied to all incoming packets.

    • 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 uniformly applied to all incoming packets.

    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 uniformly applied to all incoming packets.

    • Normalized FTP throughput is always greater than 1.

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


    Unresponsive flows
    Unresponsive Flows uniformly applied to all incoming packets.

    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 uniformly applied to all incoming packets.

    • 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 uniformly applied to all incoming packets.

    • Introduction

    • Our Approach

    • Quality Metrics

    • TSQ Mechanism

    • Evaluation

    • Conclusions and Future Work


    Conclusions
    Conclusions uniformly applied to all incoming packets.

    • 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. uniformly applied to all incoming packets.

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