1 / 33

Integrated and Differentiated Services

Integrated and Differentiated Services. Yang Richard Yang 11/5/2001. Review. Previous approaches congestion control—end host centric active queue management—light weight cannot guarantee specific service. Integrated Services. IntServ Acrhitecture. IntServ service model

hardind
Download Presentation

Integrated and Differentiated Services

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Integrated and Differentiated Services Yang Richard Yang 11/5/2001

  2. Review • Previous approaches • congestion control—end host centric • active queue management—light weight • cannot guarantee specific service

  3. Integrated Services

  4. IntServ Acrhitecture • IntServ service model • IntServ reference implementation

  5. IntServ Service Model • Real-time service • guaranteed service • predicative service • Best effort service • Controlled link-sharing

  6. Hard Real Time: Guaranteed Services • Service contract • network to client: guarantee a deterministic upper bound on delay for each packet in a session • client to network: the session does not send more than it specifies • Algorithm support • admission control based on worst-case analysis • per flow classification/scheduling at routers

  7. Soft Real Time: Controlled Load (Predicative) Service • Service contract: • network to client: similar performance as an unloaded best-effort network • client to network: the session does not send more than it specifies • Algorithm Support • admission control based on measurement of aggregates • scheduling for aggregate possible

  8. Assumptions and Implications • Resource must be explicitly managed in order to meet application requirements • what are the counter arguments? • what are the implications? • Use a common infrastructure for both real-time and non-real-time communications

  9. IntServ Reference Implementation

  10. Reference Implementation Routing RSVP Routing Messages RSVP messages Control Plane Admission Control Data Plane Forwarding Table Per Flow QoS Table Data In Route Lookup Classifier Scheduler Data Out

  11. Big Picture: The CSZ Scheme • At the top level, use WFQ to provide guaranteed service • Predicative and best-effort flows are separated by priority • how about multiple predicative classes? • How to provide link-sharing among best effort flows? What if different best-effort applications in the same link share have different requirements?

  12. Arrival curve slope r b slope R time API: Flow Specification usingToken Bucket • Characterized by two parameters (r, b) • r – average rate • b – token depth • Assume flow arrival rate <= R bps (e.g., R link capacity) • A bit is transmitted only when there is an available token • Arrival curve – maximum amount of bits transmitted by time t r bps bits b bits <= R bps regulator

  13. num hops (b,r,R,3) (b,r,R,3,D) worst-case delay RSVP: Receiver-initiated End-to-End Reservation • When R gets PATH message it knows • Traffic characteristics (tspec): (r,b,R) • Number of hops • R sends back this information + worst-case delay in RESV • Each router along path provides a per-hop delay guarantee and forwards RESV with updated info • in the simplest case, the routers can just split the delay S2 R (b,r,R) S (b,r,R,2,D-d1) S1 S3 (b,r,R,1,D-d1-d2) (b,r,R,0,0) PATH RESV

  14. Per-hop Reservation • Given (b,r,R) and per-hop delay d • Allocate bandwidth ra and buffer space Ba such that to guarantee d slope ra slope r bits Arrival curve b d Ba

  15. Soft State • Per session state has a timer associated with it • path state, reservation state • State lost when timer expires • Sender/Receiver periodically refreshes the state, resends PATH/RESV messages, resets timer • What are the advantages? • State can be explicitly deleted by a tear-down message

  16. What Are Still Missing? • Classification algorithm (will not cover in this course) • Scheduling algorithm (next class) • Admission control algorithm (will not cover in this course) • QoS Routing algorithm (will not cover in this course)

  17. Differentiated Services

  18. What is the Problem? • Intserv is • too complex • not scalable

  19. Diffserv Architecture • Ingress routers • police/shape traffic • set Differentiated Service Code Point (DSCP) in Diffserv (DS) field • Core routers • implement Per Hop Behavior (PHB) for each DSCP • process packets based on DSCP DS-2 DS-1 Egress Ingress Egress Ingress Edge router Core router

  20. Differentiated Service (DS) Field 0 5 6 7 • DS field reuses the first 6 bits from the former Type of Service (TOS) byte • The other two bits are proposed to be used by ECN DS Filed 0 4 8 16 19 31 Version HLen TOS Length Identification Flags Fragment offset IP header TTL Protocol Header checksum Source address Destination address Data

  21. Differentiated Services • Two types of service • Premium service • Assured service • Plus, best-effort service

  22. Premium Service[Jacobson ’97] • Provides the abstraction of a virtual pipe between an ingress and an egress router • Network: guarantees that premium packets are not dropped and they experience low delay • User: does not send more than the size of the pipe • if it sends more, excess traffic is delayed, and dropped when buffer overflows • What do we need in order to provide premium service?

  23. Assured Service[Clark & Wroclawski ‘97] • Defined in terms of user profile, how much assured traffic is a user allowed to inject into the network • Network: provides a lower loss rate than best-effort • in case of congestion best-effort packets are dropped first • User: sends no more assured traffic than its profile • if it sends more, the excess traffic is converted to best-effort

  24. Assured Service • Large spatial granularity service • Theoretically, user profile is defined irrespective of destination • all other services we learnt are end-to-end, i.e., we know destination(s) a priori • This makes service very useful, but hard to provision (why ?) Traffic profile Ingress

  25. DiffServ Implementation

  26. Edge Router Ingress Traffic conditioner Class 1 Marked traffic Traffic conditioner Class 2 Data traffic Classifier Scheduler Best-effort Per aggregate Classification (e.g., user)

  27. TC Performing Metering/Marking • Used to implement Assured Service • In-profile traffic is marked: • A-bit is set in every packet • Out-of-profile (excess) traffic is unmarked • A-bit is cleared (if it was previously set) in every packet; this traffic treated as best-effort r bps User profile (token bucket) b bits assured traffic in-profile traffic set A-bit metering out-of-profile traffic clear A-bit

  28. TC Performing Metering/Marking/Shaping • Used to implement Premium Service • In-profile traffic marked: • Set P-bit in each packet • Out-of-profile traffic is delayed, and when buffer overflows it is dropped r bps User profile (token bucket) b bits premium traffic Metering/ Shaper/ Set P-bit in-profile traffic out-of-profile traffic (delayed and dropped)

  29. Scheduler • Employed by both edge and core routers • For premium service – use strict priority, or weighted fair queuing (WFQ) • For assured service – use RIO (RED with In and Out) • Always drop OUT packets first • For OUT measure entire queue • For IN measure only in-profile queue Dropping probability 1 OUT IN Average queue length

  30. Scheduler Example • Premium traffic sent at high priority • Assured and best-effort traffic pass through RIO and then sent at low priority yes high priority or WFQ P-bit set? no yes low priority A-bit set? RIO no

  31. Control Path • Each domain is assigned a Bandwidth Broker (BB) • usually, used to perform ingress-egress bandwidth allocation • BB is responsible to perform admission control in the entire domain • BB not easy to implement • require complete knowledge about domain • single point of failure, may be performance bottleneck • designing BB still a research problem

  32. 3 2 7 5 1 profile profile 6 4 profile 8 9 Example • Achieve end-to-end bandwidth guarantee BB BB BB receiver sender

  33. Comparison to Best-Effort and Intserv

More Related