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

Modeling differentiated services the first step
1 / 18

  • Uploaded on
  • Presentation posted in: General

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

Modeling Differentiated Services -- the first step

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)

Load independent sharing1

Load Independent Sharing

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.

  • Login