Modeling differentiated services the first step
1 / 18

Modeling Differentiated Services -- the first step - PowerPoint PPT Presentation

  • Uploaded on

Modeling Differentiated Services -- the first step. Martin May Jean-Chrysostome Bolot Alain Jean-Marie Christophe Diot. Recap: Diffserv. Objective: Discriminate packets/flows without introducing too much complexity

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

PowerPoint Slideshow about ' Modeling Differentiated Services -- the first step' - wenda

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
Modeling differentiated services the first step

Modeling Differentiated Services-- the first step

Martin May

Jean-Chrysostome Bolot

Alain Jean-Marie

Christophe Diot

Recap diffserv
Recap: Diffserv

  • Objective: Discriminate packets/flows without introducing too much complexity

  • Trick: Instead of maintaining per-flow information at each router, let packet carry class information

  • Pros:

    • Easy to deploy, TOS bits are already there

    • Complexity only added to edge routers

  • Cons:

    • No quantitatively hard performance guarantees

How to differentiate
How to differentiate?

  • Source profiling

    • From window-based to rate-based

    • Yet another window-based algorithm

  • Resource (queue) management

    • RED: provides fairness (??)

    • CBQ, FIFO+, etc. : provides isolation

  • Packet classification and tagging

    • Classifying aggregated flows

    • Tagging in-profile packets

Why hard to model quantify
Why hard to model/quantify?

  • Source profiling

    • Most traffic are normal TCP flows

    • Actual traffic pattern is analytically intractable

  • Resource (queue) management

    • Insufficient admission control -- available bandwidth is varying over time

    • No intra-class fairness guarantee

    • Hard to study per-flow performance

  • Packet classification and tagging

    • Hard to quantify overhead

First step towards modeling
First step towards modeling

  • Simplifying source profile

    • Only looking at aggregated flows

    • Assuming Poisson arrivals for both in-profile and out-profile packets

  • Ignore implementation details

  • Study the average performance

Two one bit service models
Two (one-bit) Service Models

  • Assured Service

    • rely on selective dropping queues

    • in-profile packets are less likely to be dropped

    • good behaved sources get higher throughput

  • Premium Service

    • rely on priority queues

    • tagged (premium) packets are sent first

    • premium sources get faster transmission

Modeling assured service
Modeling Assured Service

  • Packets arrive in Poisson

  • Different dropping policies:

    • Drop-Tail (RED?): no preference

    • RIO: Drop Out packets with higher probability

    • THRESH: ONLY drop Out packets

Modeling assured service1
Modeling Assured Service

  • Assume PASTA property

    • Not valid for push-out mechanism

  • Meaningless to compare delay since most Out packets are dropped

Traffic model doesn t matter
Traffic Model Doesn't Matter

  • Almost no difference between Poisson and LRD model?!!

  • Discuss (next slide)

Traffic model does matter
Traffic Model Does Matter

  • There are actually big difference in the regime that we are interested in

Load independent sharing
Load Independent Sharing

  • “ depends only on the probability of being accepted in the last buffer position, but not on the general shape of the drop function ”

  • Having  depend on the number of tagged packets does not help much to increase the throughput of tagged flows (see next slide)

Modeling premium service
Modeling Premium Service

  • Preemptive priority queue analysis

  • Perfect isolation -- high priority packets are not affected -- ordinary M/M/1/K queue

Modeling premium service1
Modeling Premium Service

  • Low priority queue analysis

    • Approximation method 1 (coarse bound)

      • Non-preemptive priority queue (Kleinrock bound)

      • ER2= 1/ * 1/(1-1) * 1/(1-)

    • Approximation method 2 (tight bound)

      • Single M/M/1/K queue with delay busy periods

      • Only approximates the priority queue

      • ER2 = E2 +  Bj(2)

      • Discussion on computing E2 :

        • Is this a tighter or coarser bound? (see next slide)

        • How to compute Bj ?

Tighter bound
Tighter Bound??

  • Kleinrock bound is actually tighter

  • How about two M/M/1/K queue?

Delay analysis
Delay Analysis

  • Under high load, non-tagged packets suffer a very large delay

  • When overloaded ( > 1) more non-tagged packets are dropped

  • Careful engineering is necessary

Delay analysis1
Delay Analysis

  • Tradeoff between delay (NT) and loss (T)

  • Helpful for Network Dimensioning

What s next
What's Next ?

  • Is it possible to do per-flow analysis?

  • Second moment analysis

  • etc.