Ip traffic and qos control the need for flow aware networking
Download
1 / 28

IP traffic and QoS control : the need for flow aware networking - PowerPoint PPT Presentation


  • 106 Views
  • Uploaded on

NSF-COST Workshop Hania, 23-25 June 2003. IP traffic and QoS control : the need for flow aware networking. Jim Roberts http://perso.rd.francetelecom.fr/roberts France Telecom R&D. QoS and the statistical nature of demand.

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 ' IP traffic and QoS control : the need for flow aware networking' - hall


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
Ip traffic and qos control the need for flow aware networking

NSF-COST Workshop

Hania, 23-25 June 2003

IP traffic and QoS control :the need for flow aware networking

Jim Roberts

http://perso.rd.francetelecom.fr/roberts

France Telecom R&D


Qos and the statistical nature of demand
QoS and the statistical nature of demand

  • assuring QoS relies on understanding the traffic performance relationship

demand

  • volume

  • characteristics

capacity

performance

  • bandwidth

  • how it is shared

  • response time

  • loss, delay


Ip traffic is variable rate
IP traffic is variable rate

  • IP traffic is "self-similar"...

    • variability at all time scales

    • data, video, telephone,...

  • ... because of

    • heavy-tailed size distributions

    • (bandwidth sharing by TCP)

  • consequences

    • the failure of Poisson modelling?

    • the failure of the token bucket Tspec!

Ethernet traffic, Bellcore 1989


Prefer characterization at flow session level

think times

start of

session

flow

arrivals

end of

session

Prefer characterization at flow/session level

  • packets are part of "flows"...

    • a flow: all packets corresponding to one instance of a given application...

    • ... having the same identifier and occuring within a short time

  • ... flows are part of "sessions"

    • a succession of flows and "think times"

    • relating to some homogeneous user activity (e-commerce, mail,...)


Prefer characterization at flow session level1

think times

start of

session

flow

arrivals

end of

session

Prefer characterization at flow/session level

  • packets are part of "flows"...

    • a flow: all packets corresponding to one instance of a given application...

    • ... having the same identifier and occuring within a short time

  • ... flows are part of "sessions"

    • a succession of flows and "think times"

    • relating to some homogeneous user activity (e-commerce, mail,...)

  • modelling assumption: sessions occur as a Poisson process

    • in the busy period (like telephone calls!)


Traffic classification streaming elastic flows

user-network

interface

user-network

interface

network-network

interface

Traffic classification: streaming & elastic flows

  • streaming traffic

    • real time audio and video applications

    • need signal conservation, i.e., "negligible" packet loss and delay

  • elastic traffic

    • document transfers (as fast as possible): files, mail, Web, p2p,...

    • need for throughput conservation , i.e., "negligible" rate reduction with respect to external limits (access line, server capacity,...)

  • this classification is robust

    • even as new applications emerge


Performance of elastic traffic an isolated bottleneck

high throughput

low throughput

transparency (r<1)

congestion (r>1)

Performance of elastic traffic: an isolated bottleneck

  • processor sharing model of bandwidth sharing

    • assume instantaneous fair shares

    •  Pr [n flows in progress] = rn(1-r)

    •  E [throughput] = C(1-r)

  • performance is insensitive to traffic characteristics

    • only necessary traffic assumption is Poisson session arrivals!

  • its all a question of underload and overload

    • generally C(1-r)> external rate limits  throughput conservation

    • when r>1, processor sharing model is unstable  very bad performance


Box diagram for flow throughput

throughput

200 sec

start

end

10 Mbit/s

occupation

time

Box diagram for flow throughput

  • simulation results: capacity 10 Mbit/s, offered load 90%

  • visualization of per flow throughput


Box diagram for flow throughput1

> 400 Kbit/s

< 20 Kbit/s

Box diagram for flow throughput

  • simulation results: capacity 10 Mbit/s, offered load 90%

  • visualization of per flow throughput

200 sec

10 Mbit/s

time


Performance of elastic traffic an isolated bottleneck1
Performance of elastic traffic: an isolated bottleneck

  • processor sharing model of bandwidth sharing

    • assume instantaneous fair shares

    •  Pr [n flows in progress] = rn(1-r)

    •  E [throughput] = C(1-r)

  • performance is insensitive to traffic characteristics

    • only necessary traffic assumption is Poisson session arrivals!

  • its all a question of underload and overload

    • generally C(1-r)> external rate limits  throughput conservation

    • when r>1, processor sharing model is unstable  very bad performance

high throughput

low throughput

transparency (r<1)

congestion (r>1)


Extension to networks
Extension to networks

  • notions of fairness

    • max-min fairness: ideal fairness (?)

    • maximized "utility", eg, proportional balanced, but what is utility in random traffic?

    • balanced fairness: an allocation that preserves processor sharing insensitivity (cf. papers by Bonald & Proutière - http://perso.rd.francetelecom.fr/bonald )

  • how sensitive is real bandwidth sharing?

    • accounting for unfairness, TCP behaviour,...

    • still a question of underload and overload

      • r < 1-d  transparency

      • r > 1  saturation


Integration of streaming and elastic traffic
Integration of streaming and elastic traffic

  • bufferless multiplexing for streaming traffic

    • ensures controlled loss, minimal delay


Integration of streaming and elastic traffic1
Integration of streaming and elastic traffic

  • bufferless multiplexing for streaming traffic

    • ensures controlled loss, minimal delay

  • fair sharing of residual capacity for elastic flows

    • integration realized by priority queuing and TCP


Integration of streaming and elastic traffic2
Integration of streaming and elastic traffic

  • bufferless multiplexing for streaming traffic

    • ensures controlled loss, minimal delay

  • fair sharing of residual capacity for elastic flows

    • integration realized by priority queuing and TCP

  • performance model of an integrated link?

    • exact analysis is very difficult!

    • sensitive performance

    • quasi-stationary approximation


Integration of streaming and elastic traffic3
Integration of streaming and elastic traffic

  • bufferless multiplexing for streaming traffic

    • ensures controlled loss, minimal delay

  • fair sharing of residual capacity for elastic flows

    • integration realized by priority queuing and TCP

  • performance model of an integrated link?

    • exact analysis is very difficult!

    • sensitive performance

    • quasi-stationary approximation

  • a problem of local instability

    • whenAe > C – Ls

    • but not with admission control...

Ae = offered elastic traffic

Ls = current streaming load


Packet level performance

local arrival

process

Packet level performance

  • signal conservation means negligible packet loss and delay


Packet level performance1

local arrival

process

Packet level performance

  • signal conservation means negligible packet loss and delay

  • delay in one queue

    • M/DMTU/1as worst case limit of S D/D/1


Packet level performance2

local arrival

process

Packet level performance

  • signal conservation means negligible packet loss and delay

  • delay in one queue

    • M/DMTU/1as worst case limit of S D/D/1

  • accumulation of jitter

    • the "NJ conjecture":

      • M/DMTU/1remains worst case in successive queues


Traffic control
Traffic control

  • admission control for streaming traffic

    • to ensure signal conservation

    • no a priori descriptors for variable rate flows

    • must use measurement based admission control (cf. Grossglauser &Tse, 2003)


Traffic control1

congestion (r>1)

admission control (r>1)

Traffic control

  • admission control for streaming traffic

    • to ensure signal conservation

    • no a priori descriptors for variable rate flows

    • must use measurement based admission control (cf. Grossglauser &Tse, 2003)

  • admission control for elastic traffic

    • to avoid congestion collapse (and ensure throughput conservation)

    • MBAC is easy!

    • using implicit control (on the fly flow identification, no signalling, no reservation)


Traffic control2
Traffic control

  • admission control for streaming traffic

    • to ensure signal conservation

    • no a priori descriptors for variable rate flows

    • must use measurement based admission control (cf. Grossglauser &Tse, 2003)

  • admission control for elastic traffic

    • to avoid congestion collapse (and ensure throughput conservation)

    • MBAC is easy!

    • using implicit control (on the fly flow identification, no signalling, no reservation)

  • admission control on integrated link

    • facilitates MBAC for all flows

congestion (r>1)

admission control (r>1)


Cross protect avoiding explicit differentiation

measurements for admission control

priority fair

queueing

forwarding

decision

switch

fabric

priority fair

queueing

forwarding

decision

a cross protect router

"Cross protect": avoiding explicit differentiation

  • signal conservation for flows of rate < fair rate

  • throughput conservation by implicit admission control


Traffic performance in multiservice wireless networks
Traffic performance in multiservice wireless networks?

  • flows in wireless have a spatial traffic component

    • in addition to traffic characteristics relevant in wireline networks

    • wireless resource consumption depends on user position and mobility

  • the resource is not just bandwidth!

    • users consume power and contribute interference


Traffic performance in multiservice wireless networks1
Traffic performance in multiservice wireless networks?

  • flows in wireless have a spatial traffic component

    • in addition to traffic characteristics relevant in wireline networks

    • wireless resource consumption depends on user position and mobility

  • the resource is not just bandwidth!

    • users consume power and contribute interference

  • little work accounting for random elastic traffic; see however:

    • S. Borst, User-Level Performance of Channel-Aware Scheduling Algorithms in Wireless Data Networks, Infocom 2003

    • T. Bonald & A. Proutière, Wireless downlink data channels: User performance and cell dimensioning, Mobicom 2003


Conclusion
Conclusion

  • understanding the traffic performance relation

    • capacity – demand – performance

  • characterize traffic at flow (and session) level

    • streaming and elastic flows

    • Poisson arrivals


Conclusion1
Conclusion

  • understanding the traffic performance relation

    • capacity – demand – performance

  • characterize traffic at flow (and session) level

    • streaming and elastic flows

    • Poisson arrivals

  • modelling elastic bandwidth sharing

    • processor sharing model and extensions

    • a question of underload and overload!


Conclusion2
Conclusion

  • understanding the traffic performance relation

    • capacity – demand – performance

  • characterize traffic at flow (and session) level

    • streaming and elastic flows

    • Poisson arrivals

  • modelling elastic bandwidth sharing

    • processor sharing model and extensions

    • a question of underload and overload!

  • integration of streaming and elastic traffic

    • difficult to model: sensitive and locally unstable

    • negligible jitter for streaming flow packets


Conclusion3
Conclusion

  • understanding the traffic performance relation

    • capacity – demand – performance

  • characterize traffic at flow (and session) level

    • streaming and elastic flows

    • Poisson arrivals

  • modelling elastic bandwidth sharing

    • processor sharing model and extensions

    • a question of underload and overload!

  • integration of streaming and elastic traffic

    • difficult to model: sensitive and locally unstable

    • negligible jitter for streaming flow packets

  • traffic control

    • measurement-based, per-flow, implicit admission control

    • facilitated in an integrated system

    • a new proposal: the cross protect router


ad