1 / 50

Insensitivity in IP network performance

IPAM Workshop 18-19 March 2002. Insensitivity in IP network performance. Jim Roberts ( et al .) (james.roberts@francetelecom.com). Traffic theory: the fundamental three-way relationship. traffic engineering relies on understanding the relationship between demand, capacity and performance.

heba
Download Presentation

Insensitivity in IP network performance

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. IPAM Workshop 18-19 March 2002 Insensitivity in IP network performance Jim Roberts (et al.) (james.roberts@francetelecom.com)

  2. Traffic theory: the fundamental three-way relationship • traffic engineering relies on understanding the relationship between demand, capacity and performance demand • volume • characteristics capacity performance • bandwidth • how it is shared • response time • loss, delay

  3. Outline • characterizing demand • statistical bandwidth sharing • performance of elastic traffic • integrating streaming traffic • extensions for an integrated network

  4. Characterizing traffic demand • systematic traffic variations • hour of the day, day of the week,... • subject to statistical variations and growth trends • stochastic variations • model traffic as a stationary stochastic process • at the intensity of a representative demand • prefer a characterization at flow level (not packets or aggregates) • "appliflow": a set of packets from one instance of an application • two kinds of flow: streaming and elastic 50 Mb/s 50 Mb/s 0 Mb/s 0 Mb/s one day one week

  5. Streaming and elastic traffic • elastic traffic is closed-loop controlled • digital documents ( Web pages, files, ...) • rate and duration are measures of performance • QoS  adequate throughput (response time)

  6. Streaming and elastic traffic • elastic traffic is closed-loop controlled • digital documents ( Web pages, files, ...) • rate and duration are measures of performance • QoS  adequate throughput (response time) • streaming traffic is open-loop controlled • audio and video, real time and playback • rate and duration are intrinsic characteristics • QoS  negligible loss, delay, jitter

  7. think times start of session flow arrivals end of session A generic traffic model • a session consists of a succession of flows separated by "think times" • flows are streaming or elastic • think times begin at the end of each flow • sessions are mutually independent

  8. think times start of session flow arrivals end of session A generic traffic model • a session consists of a succession of flows separated by "think times" • flows are streaming or elastic • think times begin at the end of each flow • sessions are mutually independent • assume each flow is transmitted as an entity • eg, multiple TCP connections of one Web page constitute one flow

  9. think times start of session flow arrivals end of session A generic traffic model • a session consists of a succession of flows separated by "think times" • flows are streaming or elastic • think times begin at the end of each flow • sessions are mutually independent • assume each flow is transmitted as an entity • eg, multiple TCP connections of one Web page constitute one flow • sessions occur as a homogeneous Poisson process • an Internet "invariant": [Floyd and Paxson, 2001]

  10. Outline • characterizing demand • statistical bandwidth sharing • performance of elastic traffic • integrating streaming traffic • extensions for an integrated network

  11. Statistical bandwidth sharing • reactive control (TCP, scheduling) shares bottleneck bandwidth... ...unequally • depending on RTT, protocol implementation, etc. • there are no persistent flows in the Internet • utility is not a function of instantaneous rate • performance is measured by response time for finite flows • response time depends more on the traffic process than on the static sharing algorithm

  12. Performance of an isolated bottleneck • consider an isolated bottleneck of capacity C bits/s • shared by many users independently accessing many servers • performance is measured by • flow response time... • ...or realized throughput (= size / response time) users servers C bits/s

  13. Performance of an isolated bottleneck • consider an isolated bottleneck of capacity C bits/s • shared by many users independently accessing many servers • performance is measured by • flow response time... • ...or realized throughput (= size / response time) • assume (for now) Poisson flow arrivals • arrival rate l • consider a fluid model • assuming packet level dynamics realize bandwidth sharing objectives users servers C bits/s

  14. external rate limits, max_ratei(t) A fluid model of statistical bandwidth sharing • the number of flows in progress is a stochastic process • N(t) = number of flows in progress at time t • ratei(t) = rate of flow i • ratei(t) max_ratei(t) (due to other throughput limits) users servers C bits/s

  15. A fluid model of statistical bandwidth sharing • the number of flows in progress is a stochastic process • N(t) = number of flows in progress at time t • ratei(t) = rate of flow i • ratei(t) max_ratei(t) (due to other throughput limits) • assume instant max-min fair sharing... • rate of flow i, ratei(t) = min {max_ratei (t), fairshare} • where fairshare is such that Sratei(t)= min {Smax_ratei (t), C} users servers C bits/s external rate limits, max_ratei(t)

  16. A fluid model of statistical bandwidth sharing • the number of flows in progress is a stochastic process • N(t) = number of flows in progress at time t • ratei(t) = rate of flow i • ratei(t) max_ratei(t) (due to other throughput limits) • assume instant max-min fair sharing... • rate of flow i, ratei(t) = min {max_ratei (t), fairshare} • where fairshare is such that Sratei(t)= min {Smax_ratei (t), C} • ... realized approximately by TCP... • ...or more accurately by Fair Queuing users servers C bits/s external rate limits, max_ratei(t)

  17. 1 Three link bandwidth sharing models • 1. a fair sharing bottleneck • external limits are ineffective: max_ratei (t)  C, ratei(t) = C/N(t) • e.g., an access link • 2. a fair sharing bottleneck with common constant rate limit • flow bandwidth cannot exceed r: max_ratei (t)  r,ratei(t) = min {r,C/N(t)} • e.g., r represents the modem rate • 3. a transparent backbone link • max_ratei(t) << C and link is unsaturated: S max_ratei(t) < C, ratei(t) = max_ratei (t) users servers external rate limits max_ratei(t)

  18. offered traffic ls C Example: a fair sharing bottleneck (case 1) • an M/G/1 processor sharing queue • Poisson arrival ratel • mean flow size s • load r = ls/C (assume r < 1) max_ratei(t) > C ratei(t) = C/N(t)

  19. max_ratei(t) > C ratei(t) = C/N(t) Example: a fair sharing bottleneck (case 1) • an M/G/1 processor sharing queue • Poisson arrival ratel • mean flow size s • load r = ls/C (assume r < 1) • stationary distribution of number of flows in progress • p(n) = Pr [N(t) = n] • p(n) = rn (1 – r) offered traffic ls C

  20. max_ratei(t) > C ratei(t) = C/N(t) Example: a fair sharing bottleneck (case 1) • an M/G/1 processor sharing queue • Poisson arrival ratel • mean flow size s • load r = ls/C (assume r < 1) • stationary distribution of number of flows in progress • p(n) = Pr [N(t) = n] • p(n) = rn (1 – r) • expected response time of flows of size s • mean throughput = s/R(s) = C(1 – r) offered traffic ls C

  21. throughput of "mice": Pr[th'put=C/n]  p(n) throughput of "elephants":  mean = C(1 - r) C(1-r) ns simulation of TCP bandwidth sharing 1 Mbit/s Pareto size distribution Poisson flow arrivals load 0.5 1000 800 600 Throughput (Kbit/s) 400 200 0 0 500 1000 1500 2000 Size (Kbytes)

  22. C max_rate load, r 0 1 Impact of max_rate: mean throughput as a function of load E[throughput] () fair sharing:  = C(1 – r) fair sharing with rate limit:  min {max_rate, C(1 – r)}

  23. Accounting for non-Poisson flow arrivals • a stochastic network representation (cf. BCMP 1975, Kelly 1979) • sessions are customers arriving from the outside • the link is a processor sharing station • think-time is an infinite server station • ... Poisson session arrivals flows end of session link think-time

  24. Poisson session arrivals flows end of session link think-time Accounting for non-Poisson flow arrivals • ... • a network of "symmetric queues" (e.g., PS, infinite server): • customers successively visit the stations a certain number of times before leaving the network • customers change "class" after each visit - class determines service time distribution, next station and class in that station • customers arrive as a Poisson process • ...

  25. Accounting for non-Poisson flow arrivals • ... • performance of the stochastic network: • a product form occupancy distribution, insensitive to service time distributions • ... Poisson session arrivals flows end of session link think-time

  26. Accounting for non-Poisson flow arrivals • ... • bandwidth sharing performance is as if flow arrivals were Poisson • same distribution of flows in progress, same expected response time Poisson session arrivals flows end of session link think-time

  27. Accounting for non-Poisson flow arrivals • ... • bandwidth sharing performance is as if flow arrivals were Poisson • same distribution of flows in progress, same expected response time • class: a versatile tool to account for correlation in flow arrivals • different kinds of session • distibution of number of flows per session,... Poisson session arrivals flows end of session link think-time

  28. Accounting for non-Poisson flow arrivals • ... • bandwidth sharing performance is as if flow arrivals were Poisson • same distribution of flows in progress, same expected response time • class: a versatile tool to account for correlation in flow arrivals • different kinds of session • distibution of number of flows per session,... • a general performance result for any mix of elastic applications Poisson session arrivals flows end of session link think-time

  29. premium class best effort class C 0 0 C A Accounting for unfair sharing • slight impact of unequal per flow shares • e.g., green flows get 10 times as much bandwidth as red flows • approximate insensitivity throughput

  30. 1 station per route session arrivals end of session think time Extension for statistical bandwidth sharing in networks • insensitivity in PS stochastic networks with state dependent service rates • theory of Whittle networks (cf. Serfoso, 1999)... • ...applied to statistical bandwidth sharing (Bonald and Massoulié, 2001; Bonald and Proutière, 2002)

  31. number of flows throughput Underload and overload: the meaning of congestion • in normal load (i.e., r < 1): • performance is insensitive to all details of session structure • response time is mainly determined by external bottlenecks (i.e, max_rate << C) • but overloads can (and do) occur (i.e., r > 1): • due to bad planning, traffic surges, outages,... • the queuing models are then unstable, i.e., E[response time] 

  32. number of flows throughput Underload and overload: the meaning of congestion • in normal load (i.e., r < 1): • performance is insensitive to all details of session structure • response time is mainly determined by external bottlenecks (i.e, max_rate << C) • but overloads can (and do) occur (i.e., r > 1): • due to bad planning, traffic surges, outages,... • the queuing models are then unstable, i.e., E[response time]  • to preserve stability: flow based admission control!

  33. Outline • characterizing demand • statistical bandwidth sharing • performance of elastic traffic • integrating streaming traffic • extensions for an integrated network

  34. L/p packets bursts arrival rate Fluid queueing models for streaming traffic • assume flows "on" at rate p, or "off" • by shaping to rate p (e.g., isolated packet of size L = burst of length L/p)

  35. L/p packets bursts bufferless buffered arrival rate Fluid queueing models for streaming traffic • assume flows "on" at rate p, or "off" • by shaping to rate p (e.g., isolated packet of size L = burst of length L/p) • bufferless or buffered multiplexing? • Pr [arrival rate > service rate] < e • Pr [buffer overflow] < e

  36. buffer size 0 0 log Pr [overflow] Sensitivity of buffered multiplexing performance • for a superposition of N independent on/off sources service rate input rate

  37. buffer size 0 0 longer burst length shorter log Pr [overflow] Sensitivity of buffered multiplexing performance • for a superposition of N independent on/off sources • performance depends on: • mean lengths service rate input rate

  38. more variable burst length less variable Sensitivity of buffered multiplexing performance • for a superposition of N independent on/off sources • performance depends on: • mean lengths • distributions buffer size 0 0 log Pr [overflow] service rate input rate

  39. long range dependence burst length short range dependence Sensitivity of buffered multiplexing performance • for a superposition of N independent on/off sources • performance depends on: • mean lengths • distributions • correlation buffer size 0 0 log Pr [overflow] service rate input rate

  40. Sensitivity of buffered multiplexing performance • for a superposition of N independent on/off sources • performance depends on: • mean lengths • distributions • correlation • sensitivity precludes precise control • prefer bufferless multiplexing buffer size 0 0 long range dependence burst length short range dependence log Pr [overflow] service rate input rate

  41. service rate Bufferless multiplexing (alias rate envelope multiplexing) • ensure negligible probability of rate overload • Pr[input rate > service rate] <  • by provisioning • accounting for session/flow process and rate fluctuations within each flow • and using admission control to preserve transparency • measurement-based admission control (e.g. Gibbens et al., 1995) input rate

  42. Insensitive performance of bufferless multiplexing • assuming Poisson session arrivals and peak rate p: • traffic offered = a bit/s, capacity = C bit/s bursts Poisson session arrivals end of session link silence/ think-time

  43. Insensitive performance of bufferless multiplexing • assuming Poisson session arrivals and peak rate p: • traffic offered = a bit/s, capacity = C bit/s • i.e., loss depends only on load (a/C) and link/peak rate ratio (C/p) • for any mix of streaming applications bursts Poisson session arrivals end of session link silence/ think-time

  44. Efficiency of bufferless multiplexing • small amplitude of rate variations ... • peak rate << link rate (eg, 1%) • e.g., C/p = 100  Pr [overflow] < 10-6 for a/C < 0.6 • ... or low utilisation • overall mean rate << link rate

  45. Efficiency of bufferless multiplexing • small amplitude of rate variations ... • peak rate << link rate (eg, 1%) • e.g., C/p = 100  Pr [overflow] < 10-6 for a/C < 0.6 • ... or low utilisation • overall mean rate << link rate • we may have both in an integrated network • priority to streaming traffic • residue shared by elastic flows

  46. Integrating streaming and elastic flows • scheduling required to meet QoS requirements • priority to streaming flows • fair sharing of residual capacity by elastic flows (TCP or FQ?)

  47. Integrating streaming and elastic flows • scheduling required to meet QoS requirements • priority to streaming flows • fair sharing of residual capacity by elastic flows (TCP or FQ?) • realizing a performance synergy • very low loss for streaming data • efficient use of residual bandwidth by elastic flows

  48. Integrating streaming and elastic flows • scheduling required to meet QoS requirements • priority to streaming flows • fair sharing of residual capacity by elastic flows (TCP or FQ?) • realizing a performance synergy • very low loss for streaming data • efficient use of residual bandwidth by elastic flows • complex performance analysis • a PS queue with varying capacity (cf. Delcoigne, Proutière, Régnié, 2002) • exhibits local instability and sensitivity (in heavy traffic with high stream peak rate)... • ... but a quasi-stationary analysis is accurate when admission control is used

  49. Conclusion: • we need to account for the statistical nature of traffic • a Poisson session arrival process • fair sharing for insensitive elastic flow performance • slight impact of unfairness (cf. Bonald and Massoulié, 2001) • fair sharing in a network (cf. Bonald and Proutière, 2002) • bufferless multiplexing for insensitive streaming performance • choosing a common maximum peak rate (C/p > 100 for efficiency) • packet scale performance (jitter accumulation)? • synergistic integration of streaming and elastic traffic • quasi-insensitivity with admission control (cf. Delcoigne et al., 2002, Benameur et al., 2001)

  50. Conclusion: • we need to account for the statistical nature of traffic • a Poisson session arrival process • fair sharing for insensitive elastic flow performance • slight impact of unfairness (cf. Bonald and Massoulié, 2001) • fair sharing in a network (cf. Bonald and Proutière, 2002) • bufferless multiplexing for insensitive streaming performance • choosing a common maximum peak rate (C/p > 100 for efficiency) • packet scale performance (jitter accumulation)? • synergistic integration of streaming and elastic traffic • quasi-insensitivity with admission control (cf. Delcoigne et al., 2002, Benameur et al., 2001) • required congestion control mechanisms • implicit measurement-based admission control • shaping and priority queuing and reliance on TCP... • ... or per-flow fair queuing for all?

More Related