Unformatted text preview:

1CS640: Introduction to Computer NetworksAditya AkellaLecture 21 –QoS2The Road Ahead• Admission Control• Integrated services• RSVP• Differentiated Services3Why a New Service Model?• Best-effort is clearly insufficient• What is the basic objectiveof network design?– Maximize total bandwidth? Minimize latency?–Maximize user satisfaction– the total utility given to users• What does utility vs. bandwidth look like?– Must be non-decreasing function – Shape depends on application24Utility Curve ShapesStay to the right and youare fine for all curvesBWUElasticBWUHard real-timeBWUDelay-adaptive5Utility curve – Elastic trafficBandwidthUElasticDoes equal allocation of bandwidth maximize total utility?6Elastic Traffic• If U(bandwidth) is concave elastic applications– Incremental utility is decreasing with increasing bandwidth– Is always advantageous to have more flows with lower bandwidth• No need of admission control;This is why the Internet works!BWUElastic37Utility Curves – Inelastic trafficBWUHard real-timeBWUDelay-adaptiveDoes equal allocation of bandwidth maximize total utility?8Admission Control• If U is convex inelastic applications– U(number of flows) is no longer monotonically increasing– Need admission control to maximize total utility•Admission controldeciding when the addition of new people would result in reduction of utility– Basically avoids overload• We will see how these issues play out in real QoSimplementationsBWUDelay-adaptive9QoS Instantiation #1:Integrated ServicesKey components:1. Type of commitmentWhat does the network promise?2. Packet schedulingHow does the network meet promises?3. Service interfaceHow does the application describe what it wants?4. Establishing the guarantee (gory details)How is the promise communicated to/from the networkHow is admission of new applications controlled?410Type of Commitments•Guaranteed service– For hard real-timeapplications– Fixed guarantee, network meets commitment as long as rates clients send at match traffic agreement•Predicted service– For delay-adaptiveapplications– Two components• If conditions do not change, commit to current service• If conditions change, take steps to deliver consistent performance (help apps minimize playback delay)• Implicit assumption – network does not change much over time•Datagram/best effort service11Scheduling for Guaranteed Traffic• Use token bucket filterto characterize traffic– Described by rate rand bucket depth b• Use Weighted Fair-Queueingat the routers• Parekh’s bound for worst case queuing delay = b/r12Token Bucket FilterTokens enter bucket at rate rBucket depth b: capacity of bucketOverflowTokensTokensPacketEnough tokens packet goes th rough,tokens re movedTokensPacketNot enough tokens wait for tokens to accumulat e513Token Bucket Characteristics• On the long run, rate is limited to r• On the short run, a burst of size b can be sent• Amount of traffic entering at interval T is bounded by:– Traffic = b + r*T• Information useful to admission algorithm14Token Bucket SpecsBWTime121 2 3Flow AFlow BFlow A: r = 1 MBps, B=1 byteFlow B: r = 1 MBps, B=1MB15Guarantee Proven by Parekh• Given:– Flow ishaped with token bucket and leaky bucket rate control (depth band rater)– Network nodes do WFQ• Cumulative queuing delay Disuffered by flow ihas upper bound–Di < b/r,(where r may be much larger than average rate)– Assumes that Σr< link speed at any router– All sources limiting themselves to rwill result in no network queuing616Sharing versus Isolation• Isolation– Isolates well-behaved from misbehaving sources• Sharing– Mixing of different sources in a way beneficial to all• FIFO: sharing– each traffic source impacts other connections directly• e.g. malicious user can grab extra bandwidth– the simplest and most common queueing discipline– averages out the delay across all flows• Priority queues: one-way sharing– high-priority traffic sources have impact on lower priority traffic only– has to be combined with admission control and traffic enforcement to avoid starvation of low-priority traffic • WFQ: two-way isolation– provides a guaranteed minimum throughput (and maximum delay)17Putting It All Together• Assume 3 types of traffic: guaranteed, predictive, best-effort• Scheduling: use WFQ in routers• Each guaranteed flow gets its own queue• All predicted service flows and best effort aggregates in single separate queue– Predictive traffic classes• Worst case delay for classes separated by order of magnitude• When high priority needs extra bandwidth – steals it from lower class– Best effort traffic acts as lowest priority class18Resource Reservation Protocol(RSVP)• Carries resource requests all the way through the network• Main goal: establish “state” in each of the routers so they “know” how they should treat flows.– State = packet classifier parameters, bandwidth reservation, ..• At each hop consults admission control and sets up reservation. Informs requester if failureABCD719PATH Messages• PATH messages carry sender’s Tspec– Token bucket parameters• Routers note the direction PATH messages arrived and set up reverse pathto sender• Receivers send RESV messages that follow reverse path and setup reservations• If reservation cannot be made, user gets an error20RESV Messages• Forwarded via reverse path of PATH• Queuing delay and bandwidth requirements• Source traffic characteristics (from PATH)• Filter specification– Which transmissions can use the reserved resources• Router performs admission control and reserves resources– If request rejected, send error message21Soft State• Periodic PATH and RESV msgs refresh established reservation state – Path messages may follow new routes– Old information times out• Properties– Adapts to changes in routes and sources– Recovers from failures– Cleans up state after receivers drop out822Differentiated Services:Motivation and Design• Edge routers do fine grain enforcement– Typically slower links at edge– E.g. mail sorting in post offices– Label packets with a type field • Uses IP TOS bits• E.g. a priority stamp• Core routers process packets based on packet marking and defined per hop behavior• More scalable than IntServ– No signaling– No per-flow state in the coreClassification and conditioning23DiffServ Examplefirst


View Full Document

UW-Madison CS 640 - Lecture 21

Documents in this Course
Security

Security

21 pages

Mobile IP

Mobile IP

16 pages

Lecture 7

Lecture 7

36 pages

Multicast

Multicast

38 pages

Load more
Download Lecture 21
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 21 and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 21 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?