modeling differentiated services the first step
Skip this Video
Download Presentation
Modeling Differentiated Services -- the first step

Loading in 2 Seconds...

play fullscreen
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.