ch05-traffic_mgt

ch05-traffic_mgt - Chapter 5 Traffic management Master...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Chapter 5 Traffic management Master F2006 An example A worldwide videoconference is organized. Different groups are participating. Proceedings are videotaped and stored in different archives Proceedings are edited and placed on web sites, which may be accessed later by several people. During the conference, different actions may be required: Sending email between participating people, Breaks off to answer a voice call What is required For video : need for sustained bandwidth (higher than 64 kbps), low loss rate For voice: need for sustained bandwidth (higher than 8 kbps), low loss rate For interactive communication: low delays are required (< 100 ms one-way) For playback: low delay jitter For email and archiving: reliable bulk transport What if: A million executives were simultaneously accessing million the network the What capacity should each access have? What capacity How should packets be routed? (Can we spread load How routed (Can over alternate paths?) over How can different traffic types get different services How services from the network? from How should each endpoint regulate its load? How regulate How should we price the network usage? How price These types of questions lie at the heart of network These design and operation, and form the basis for traffic design management. management. Traffic management Set of policies and mechanisms that allow a network to efficiently satisfy a diverse range of service requests Tension is between diversity and efficiency Traffic management is necessary for providing Quality of Service (QoS) Subsumes congestion control (congestion == loss of efficiency) Traffic management = Connectivity + Quality of Service One of the most challenging open problems in networking: At the heart of the next generation of data networks Outline Economic principles Traffic classes Time scales Mechanisms Mechanisms Some open problems Some 1. Economic Principles: Utility function Users are assumed to have a utility function that maps any given quality of service to a level of satisfaction, or utility Utility functions are private information Cannot compare utility functions between users (in Cannot general) general) Rational users take actions that maximize their utility Can determine utility function by observing preferences Example Let utility function defined by u = S - a t u = utility from file transfer S = satisfaction when transfer infinitely fast t = transfer time a = rate at which satisfaction decreases with time As transfer time increases, utility decreases If t > S/a, user is worse off! (reflects time wasted) S and a can be experimentally determined Social welfare Suppose network manager knew the utility function of every user Social Welfare is maximized when some combination of the utility functions (such as sum) is maximized An economy (network) is efficient when increasing the utility of one user must necessarily decrease the utility of another An economy (network) is envy-free if no user would trade places with another (better performance also costs more) Goal: maximize social welfare subject to efficiency, envy-freeness, and making a profit Example Assume Single switch, each user imposes load 0.4 Single 0.4 A's utility: 4 - d A's B’s utility : 8 - 2d B’s 2d Same delay to both users Conservation law 0.4d + 0.4d = C => d = 1.25 C => 0.4d => sum of utilities = 12-3.75 C sum Sum of utilities = 12 - 3C of If B’s delay reduced to 0.5C, then A’s delay = 2C If 0.5C Some economic principles s A single network that provides heterogeneous QoS is better than separate networks for each QoS unused capacity is available to others s Lowering delay of delay-sensitive traffic increased welfare can increase welfare by matching service menu to user requirements s For typical utility functions, welfare increases more than linearly with increase in capacity individual users see smaller overall fluctuations can increase welfare by increasing capacity 2. Traffic classes Networks should match offered service to source requirements (corresponds to utility functions) Example: telnet requires low bandwidth and low delay utility increases with decrease in delay network should provide a low-delay service or, telnet belongs to the low-delay traffic class Traffic classes encompass both user requirements and network service offerings Traffic classes A basic division: guaranteed service and best effort Guaranteed-service utility is zero unless application gets a minimum level of service quality (bandwidth, delay, loss) open-loop flow control with admission control e.g. telephony and remote sensing, interactive multiagent systems s Best-effort send and hope easy flow control GS vs. BE s Degree of synchrony x time scale at which peer endpoints interact GS are typically synchronous or interactive GS interactive 3 interact on the timescale of a round trip time 3 e.g. telephone conversation or telnet BE are typically asynchronous or non-interactive BE non-interactive 3 interact on longer time scales 3 e.g. Email GS apps are real-time GS real-time 3 performance depends on wall clock BE apps are typically indifferent to real time 3 automatically scale back during overload s Sensitivity to time and delay Traffic subclasses (roadmap) s ATM Forum x s IETF x x x based on sensitivity based to bandwidth to GS GS 3 CBR, VBR BE 3 ABR, UBR x x based on sensitivity to based delay delay GS 3 Intolerant Intolerant 3 tolerant BE 3 interactive burst 3 interactive bulk 3 asynchronous bulk ATM Forum GS subclasses s Constant Bit Rate (CBR) constant, cell-smooth traffic mean and peak rate are the same e.g. telephone call evenly sampled and uncompressed constant bandwidth, variable quality s Variable Bit Rate (VBR) long term average with occasional bursts try to minimize delay can tolerate loss and higher delays than CBR e.g. compressed video or audio with constant quality, e.g. variable bandwidth variable ATM Forum BE subclasses s Available Bit Rate (ABR) users get whatever is available zero loss if network signals (in RM cells) are obeyed no guarantee on delay or bandwidth Unspecified Bit Rate (UBR) s like ABR, but no feedback no guarantee on loss presumably cheaper IETF GS subclasses s Tolerant GS nominal mean delay, but can tolerate “occasional” nominal variation variation not specified what this means exactly uses controlled-load service uses 3 book uses older terminology (predictive) even at “high loads”, admission control assures a even source that its service “does not suffer” source Intolerant GS s need a worst case delay bound equivalent to CBR+VBR in ATM Forum model IETF BE subclasses s s s Interactive burst bounded asynchronous service, where bound is bounded qualitative 3 e.g. paging, messaging, email Interactive bulk bulk, but a human is waiting for the result e.g. FTP Asynchronous bulk Bursty traffic e.g netnews 3. Time scales s Some actions are taken once per call tell network about traffic characterization and request tell resources resources in ATM networks, finding a path from source to in destination destination Other actions are taken during the call, every few round trip Other times times feedback flow control Still others are taken very rapidly, during the data transfer Scheduling, policing and regulation Traffic management mechanisms must deal with a range of Traffic traffic classes at a range of time scales traffic s s s Summary of mechanisms at each time scale s Less than one round-trip-time (cell-level) Scheduling and buffer management Regulation and policing Policy routing (datagram networks) One or more round-trip-times (burst-level) Feedback flow control Retransmission Renegotiation Session (call-level) s s Signalling Admission control Service pricing Routing (connection-oriented networks) Outline s s s s s Economic principles Traffic classes Time scales Mechanisms Some open problems 4. Mechanisms: Renegotiation s s An option for guaranteed-service traffic Static descriptors do not make sense for many real traffic Static sources (ex, interactive video) interactive Multiple-time-scale traffic s burst size B that lasts for time T for zero loss, descriptors: P = peak rate, A = average T llarge => serving even slightly below P leads to large arge buffering requirements buffering one-shot descriptor is inadequate Renegotiation (cont.) s s Renegotiation matches service rate to traffic Renegotiating service rate about once every ten seconds Renegotiating is sufficient to reduce bandwidth requirement nearly to average rate average Fast buffer reservation is similar each burst of data preceded by a reservation Renegotiation is not free of cost s s signalling overhead call admission ? call 3 perhaps measurement-based admission control Signalling s s How a source tells the network its utility function Two parts how to carry the message (transport) how to interpret it (semantics) Useful to separate these mechanisms s Signaling semantics s s s s s Classic scheme: sender initiated SETUP, SETUP_ACK, SETUP_RESPONSE Admission control Tentative resource reservation and confirmation Simplex and duplex setup Doesn’t work for multicast s Resource translation s s Application asks for end-to-end quality How to translate to per-hop requirements? E.g. end-to-delay bound of 100 ms What should be bound at each hop? Two-pass s forward: maximize (denial!) reverse: relay open problem! Admission control s s Can a call be admitted? CBR admission control simple on failure: try again, reroute, or wait Best-effort admission control s trivial if minimum bandwidth needed, use CBR test VBR admission control s VBR peak rate differs from average rate = burstiness peak burstiness if we reserve bandwidth at the peak rate, wastes if bandwidth bandwidth if we reserve at the average rate, may drop packets if during peak during key decision: how much to overbook Three major approaches s peak rate admission control admission control with statistical guarantees measurement-based admission control Peak-rate admission control s s Reserve at a connection’s peak rate Advantages x x x simple (can use FIFO scheduling) connections get zero delay and zero loss works well for a small number of sources wastes bandwidth peak rate may increase because of scheduling jitter peak s Disadvantages x x rate time Admission with statistical guarantees s Key insight is that as # calls increases, probability that Key multiple sources send a burst decreases multiple sum of connection rates is increasingly smooth With enough sources, traffic from each source can be With assumed to arrive at its average rate assumed Put in enough buffers to make probability of loss low s s Admission with statistical guarantees s 2 s s s s s Assume that traffic from a source is sent to a buffer of Assume size B which is drained at a constant rate e If source sends a burst, its delay goes up If the burst is too large, bits are lost Equivalent bandwidth of the source is the rate at which we need to drain this buffer so that the probability of loss is less than l and the delay in leaving the buffer is less than d If many sources share a buffer, the equivalent bandwidth If of each source decreases of Equivalent bandwidth of an ensemble of connections is Equivalent the sum of their equivalent bandwidths the Admission with statistical guarantees 3 s When a source arrives, use its performance When requirements and current network state to assign it an equivalent bandwidth equivalent Admission control: sum of equivalent bandwidths at the Admission link should be less than link capacity link Advantages: s s can trade off a small loss probability for a large decrease in can bandwidth reservation bandwidth mathematical treatment possible can obtain delay bounds s Disadvantages: assumes uncorrelated sources hairy mathematics Measurement-based admission s For traffic that cannot describe itself also renegotiated traffic s s s s s Measure ‘real’ average load Users tell peak If peak + average < capacity, then admit Over time, new call becomes part of average Problems: assumes that past behaviour is indicative of the future how long to measure? when to forget about the past? Capacity planning s How to modify network topology, link capacity, and routing How to most efficiently use existing resources, or alleviate longto term congestion Usually a matter of trial and error A more systematic approach: 1. 2. 3. 4. s s measure network during its busy hour create traffic matrix decide topology assign capacity Measure network during busy hour s s Traffic varies during day and during week A good rule to handle this is to build for the worst case good traffic traffic Measure traffic for some period of time, then pick the Measure busiest hour busiest Usually add an extra factor for future growth Measure bits sent from each endpoint to each endpoint Measure (assuming that endpoint remain the same, only the internal assuming network topology is being redesigned) network s s s Create traffic matrix s Traffic matrix counts the Numbers of bits sent from each Traffic source to each destination source We assume that the pattern predicts future behaviour s This is probably a weak assumption (what if a web site what suddenly becomes popular!) suddenly s s Traffic over shorter time scales may be far heavier Doesn’t work if we are adding a new endpoint can assume that it is similar to an existing endpoint Decide topology s Topology depends on three considerations k-connectivity path should exist between any two points despite path single node or link failures single geographical considerations some links may be easier to build than others existing capacity Assign capacity s s Assign sufficient capacity to carry busy hour traffic Unfortunately, actual path of traffic depends on routing Unfortunately, protocols which measure instantaneous load and link status status So, we cannot directly influence path taken by traffic Circular relationship between capacity allocation and Circular routing makes problem worse routing s s higher capacity link is more attractive to routing thus carries more traffic thus requires more capacity s Easier to assign capacities if routing is static and links are Easier static always up always Capacity allocation s s s s s Blocking probability along a path Blocking Assume traffic on links is independent Then, probability is product of probability on each link Routing table + traffic matrix tells us load on a link Assign capacity to each link given load and target Assign blocking probability blocking Or, add a new link and change the routing table s Problems with capacity planning s s s Routing and link capacity interact Measurements of traffic matrix Survivability 5. Open problems s s s s s Resource translation Resource Renegotiation Measurement-based admission control Peak-load pricing Capacity planning 1. Resource translation s s s s Application asks for end-to-end quality in terms of Application bandwidth and delay bandwidth How to translate to resource requirements in the How network? network? Bandwidth is relatively easy, delay is hard One approach is to translate from delay to an equivalent One bandwidth bandwidth x x can be inefficient if need to use worst case delay bound average-case delay usually requires strong source average-case characterization characterization s s Other approach is to directly obtain per-hop delay bound Other (for example, with EDD scheduling) (for How to translate from end-to-end to per-hop How requirements? requirements? 2. Renegotiation s Static descriptors don’t make sense for interactive Static sources or multiple-time scale traffic sources Renegotiation matches service rate to traffic Renegotiation is not free- incurs a signaling overhead Renegotiation Open questions x x x x s s s when to renegotiate? how much to ask for? admission control? what to do on renegotiation failure? 3. Measurement based admission s For traffic that cannot describe itself also renegotiated traffic Over what time interval to measure average? How to describe a source? How to account for nonstationary traffic? Are there better strategies? x s s s s 4. Peak load pricing s s s How to choose peak and off-peak prices? When should peak hour end? What does peak time mean in a global network? 5. Capacity planning s Simultaneously choosing a topology, link capacity, and Simultaneously routing metrics routing But routing and link capacity interact What to measure for building traffic matrix? How to pick routing weights? Heterogeneity? s s s s ...
View Full Document

Ask a homework question - tutors are online