Traffic modelling and traffic control are necessary for

  • Slides: 3
Download presentation
Traffic modelling and traffic control. . . è. . . are necessary for Qo.

Traffic modelling and traffic control. . . è. . . are necessary for Qo. S (or qos) and this is still an issue 4(over)provisioning. . . 4. . . and controlled sharing è Qo. S tends to mean "hard" qos (Intserv-like) 4 for an announced connection – a priori traffic descriptor, admission control, scheduling and/or traffic conditioning 4 statistical network calculus is the state of the art in realizing hard Qo. S guarantees (delay < d, negligible loss) è Diffserv is softer qos 4 aggregate descriptors, conditioning and per hop behaviours 4 but how can we meet the SLA's? è some believe even softer qos is sufficient (and necessary? ) 4 a self-managed Internet. . . 4. . . or a network with implicit admission control and implicit differentiation è we also need modelling to understand best effort control! 4 eg, Ne. Xtworking’ 03 TCP modelling and re-design June 23 -25, 2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING Roberts 1

Answering the questions è is standard queueing theory enough? 4 frequently: model at the

Answering the questions è is standard queueing theory enough? 4 frequently: model at the appropriate granularity, seek insensitivities è is first course control theory enough? 4 significant advances: cf. work on stability of TCP è how can we understand time-scale interactions and design for them? 4 time scale separation is key to successful modelling 4 but beware of drawing conclusions without regard to all time scales è are time varying averages enough, or do we need to capture higher moments? 4 insensitivity results suggest time averages are often sufficient 4 stationarity is a key assumption – is this valid with LRD traffic? Ne. Xtworking’ 03 June 23 -25, 2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING Roberts 2

Answering the questions è what happens to "effective" bandwidth and good old Erlang? 4

Answering the questions è what happens to "effective" bandwidth and good old Erlang? 4 effective bandwidth is useful for sizing 4 Erlang is still insensitive. . . to criticism! è why are we insisting on modelling TCP and RED 4 evolution to higher rates, ensure stability, improve fairness? improve efficiency? è why did it take us some time to be more careful? 4 self-similarity vs pseudo ss, limit cycle vs instability, etc 4 who was not careful? who is now more careful? Ne. Xtworking’ 03 June 23 -25, 2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING Roberts 3