CS 268: Lecture 12 QoS: DiffServ and IntServ More “Why” Than “What”Quality of ServiceThree Relevant FactorsProviding Better ServiceRelative QoSDifferentiated Services (DiffServ)DiffServ ArchitectureTraffic Policing/ShapingImplementing Drop PrioritySender and Receiver VersionsCombining Drop and Delay PriorityWhy Does Giving Priority Help?From Relative to Absolute ServiceProviding AssurancesInter-Domain Premium DiffServFrom DiffServ to IntServMajor Philosophical ChangeReservations or Best-EffortModeling Application PerformanceClasses of ApplicationPlayback ApplicationsClasses of ApplicationsElastic ApplicationsRigid Real-Time ApplicationsAdaptive Real-Time ApplicationsBack to QuestionThought ExperimentMathematical FormulationResultsConclusionSlide 31What Have We Ignored?Reservations vs Best-EffortVariable LoadWhy Shouldn’t This Kill IntServ?The Overprovisioning DebateIntServKey IntServ Design DecisionsIntegrated Services InternetIntServ MechanismsIntServ ServicesIntegrated Services ExampleSlide 43Slide 44Slide 45Integrated Services Example: Data PathSlide 47Slide 48How Things Fit TogetherRSVP Reservation ProtocolThe Big PictureThe Big Picture (2)RSVP Basic OperationsRoute PinningPATH and RESV messagesReservation StyleReservation Styles: FiltersWhat Did We Miss?1CS 268: Lecture 12QoS: DiffServ and IntServMore “Why” Than “What”Scott Shenker and Ion StoicaComputer Science DivisionDepartment of Electrical Engineering and Computer SciencesUniversity of California, BerkeleyBerkeley, CA 94720-17762Quality of ServiceTraditional Internet gives single class of best-effort service-Even though ToS bits were included in the original IP headerTreats all packets the same-All customers-All applicationsShould Internet give better quality service to some packets?-Why?-Why not?3Three Relevant FactorsApplication performanceBandwidth required to provide performanceComplexity/cost of required mechanisms4Providing Better ServiceRouting or ForwardingScheduling or DroppingRelative or Absolute5Relative QoSPriority scheduling-Favored packets get lower delay and lower drop ratePriority dropping-All sent packets get same average delayWhy bother with priority dropping?6Differentiated Services (DiffServ)Goal: offer different levels of service-Organized around domains-Edge and core routersEdge routers-Sort packets into classes (based on variety of factors)-Police/shape traffic-Set bits (DSCP) in packet headerCore routers -Handle packet (PHB) based on DSCP7DiffServ ArchitectureIngressEgressEgressIngressEgressEgressDS-1DS-2Edge routerCore router8Traffic Policing/ShapingToken bucket (r,b) [everyone know this?]Police: if token is available, packet is considered “in”-Otherwise considered “out”Shape: packet is delayed until token is available9Implementing Drop PriorityRED in/out (RIO)Separate dropping curves for in and out traffic-Out curve measures all packets-In curve measures only in packets OUT INAverage queue length 1Droppingprobability10Sender and Receiver VersionsSender-based version: -Sender (or token bucket next to sender) sets in/out bits-Routers service with priorityReceiver-based version: use ECN-Put incoming packets through token bucket-If packet is “in”, cancel any ECN bits-Receiver only told about congestion for “out” packets11Combining Drop and Delay PriorityDelay priority traffic gets high forwarding priorityDrop priority traffic uses RIODelayP?DropP? RIOyesnoyesnohigh forwarding prioritylow forwarding priority12Why Does Giving Priority Help?Making service for one class of traffic better means that service for another class of traffic must get worseWhy does that help?13From Relative to Absolute ServicePriority mechanisms can only deliver absolute assurances if total load is regulatedService Level Agreements (SLAs) specify:-Amount user (organization, etc.) can send-Level of service delivered to that trafficPremium Service (DiffServ) offers low (unspecified) delay and no drops-Acceptance of proposed SLAs managed by “Bandwidth Broker”-Only over long time scales14Providing AssurancesSLAs are typically defined without restriction on destinationCan’t provision network efficiently, but may not matter IngressTraffic profile15Inter-Domain Premium DiffServAchieve end-to-end bandwidth guaranteeBut is this done for all paths?BBBBBBBBBBBB123579senderreceiver8profile6profile4profile16From DiffServ to IntServCan easily provide some traffic better service than others-Making absolute assurances requires controlling loadDiffServ worst-case provisioning very inefficient -Based on aggregate offered load, not for a specific pathWhat about fine-grain assurances about QoS?-Per-flow, not per traffic classRequires admission control for each flow-E.g., reservations17Major Philosophical ChangePer-flow admission control is drastic change to the Internet-But best-effort still available (used for most traffic)We will first discuss whether this is a good idea-Going back to basics about application performance, etc.We will then talk about how one might do this-Cursory overview, because details are in the dustbin of history18Reservations or Best-EffortBasic question: -Should we admit all flows (BE), or -Refuse some to preserve good service for current flows (R)Precedents:-The telephone network uses admission control-The current Internet does notWhich one is right? Huge ideological battle!!How can we decide?-Which provides better application performance?19Modeling Application PerformanceNot a simple function of delay/jitter/lossDepends on user perception-e.g., picture quality, etc.Depends on adaptive application behavior-Adjust sending rate-Adjust coding (to mask errors)-Adjust “playback point” (later)For a given application, can describe performance as a function of available bandwidth20Classes of ApplicationTraditional data applications: “elastic”-Tolerant of delay-Tolerant of lossStreaming media applications: “real-time”-Less tolerant of delay-Less tolerant of loss-Often of the “playback” variety21Playback ApplicationsVideo/audio stream being sent“Played back” at receiverReceiver picks time to play back content-“playback point”Playback point:-Moves: distortion-Late: delay-Misses packets: “drops”22Classes of ApplicationsElastic:-Tolerant of delays and lossesReal-time:-Rigid (can’t tolerate
View Full Document