Presentation is loading. Please wait.

Presentation is loading. Please wait.

© Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet.

Similar presentations


Presentation on theme: "© Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet."— Presentation transcript:

1 © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet

2 © Jörg Liebeherr, 1998-2002 2 Quality of Service What is Quality-of-Service? QoS refers to traffic control mechanisms that seek to either differentiate performance based on application or network- operator requirements, or provide predictable or guaranteed performance to applications, sessions, or traffic aggregates. Why is this an issue? The default service in many packet networks is to give all applications the same service, and not consider any service requirements to the network This is called a best-effort service.

3 © Jörg Liebeherr, 1998-2002 3 Quality of Service Who needs Quality-of-Service? –Video and audio conferencing  bounded delay and loss rate –Video and audio streaming  bounded packet loss rate –Time-critical applications (real-time control)  bounded delays –“valuable applications”  better service than less valuable applications How are Quality-of-Service requirements specified? QoS requirements can be specified as –Delay –Delay Variation (Jitter) –Throughput –Error Rate

4 © Jörg Liebeherr, 1998-2002 4 Components of a QoS Network 1.At routers: Packet Classification, Packet Scheduling 2.At network entrance: Traffic conditioning 3.At routers or somewhere in the network: Admission Control 4.Between hosts and routers: Signaling Sender ReceiverRouters Admission control Traffic conditioning

5 © Jörg Liebeherr, 1998-2002 5 Classification and Scheduling Routers need to be able to 1.classify arriving packets according to QoS requirements  Packet Classification 2.Transmit packets in order to meet QoS  Packet Scheduling

6 © Jörg Liebeherr, 1998-2002 6 Traffic Conditioning Traffic conditioning mechanisms at the network boundary need to enforce that traffic from a flow does not exceed specification  Policing Drop traffic that violates specification  Shaping Buffer traffic that violates specification  Marking Mark packets with a lower priority or as best effort, if the traffic specification is violated

7 © Jörg Liebeherr, 1998-2002 7 Traffic Conditioning The most popular traffic conditioning algorithm is the leaky bucket Token pool (Bucket) has depth b r token/sec are added (no tokens are added if there are b tokens) Network A shaper buffers packets until a token becomes available A policer drops a packet if no token is available Each packet removes a token from the pool. If pool is empty, packet cannot enter

8 © Jörg Liebeherr, 1998-2002 8 Admission Control Admission Control is a function that decides if the network has enough resources –Admit new flow if enough resources are available –Reject the flow otherwise Sender ReceiverRouters Traffic conditioning I need100 ms delay for 1 Mbps traffic Admit Reserve capacity Admission control

9 © Jörg Liebeherr, 1998-2002 9 Example: End-to-end delay must be less than a delay bound D Calculate smallest possible delay bound at each node: d* 1, d* 2, d* 3 and reserve resources At receiver: –If D < d* 1 + d* 2 + d* 3, reject flow, send reject message to sender and release resources –If D > d* 1 + d* 2 + d* 3, accept flow, commit resource reservation and notify sender Distributed Admission Control 12 3 D < d 1 +d 2 +d 3  Reject S R D D,d 1 D,d 1,d 2 D,d 1,d 2,d 3 Reject D > d 1 +d 2 +d 3  Accept Accept

10 © Jörg Liebeherr, 1998-2002 10 Signaling Protocol is used to reserve and release resources and to do admission control Signaling 12 3 S R Reserve 1 Mbps

11 © Jörg Liebeherr, 1998-2002 11 Granularity of QoS Per-flow guarantees –Require per-flow reservations in the network –Require per-flow classification at routers

12 © Jörg Liebeherr, 1998-2002 12 Granularity of QoS 1 1 2 2 1 1 2 2 1 1 2 2 2 1 2 1 2 1 1 2 1 2 2 1 Per-class guarantees –Bundle traffic flows with similar service requirements into “classes” –No per-flow reservations –Per-class guarantees do not immediately translate into per-flow guarantees

13 © Jörg Liebeherr, 1998-2002 13 QoS Service Architectures for the Internet Two QoS architectures have been defined for Internet. –Integrated Services (IntServ) Proposed in 1994 Per-flow Quality of Service Resource reservation/admission control Can support delay guarantees –Differentiated Services (DiffServ) Proposed in 1998 Class-based QoS Resource reservation not always needed

14 © Jörg Liebeherr, 1998-2002 14 Integrated Services IntServ specifies two types of services: Guaranteed Service –Guaranteed bandwidth –End-to-end delay bounds –No loss due to buffer overflows Controlled Load Service –Provides a service that is equivalent to a best effort service in a lightly loaded network Low loss Low delay No absolute guarantees

15 © Jörg Liebeherr, 1998-2002 15 Integrated Services 1.At network entrance: Policing and Shaping 2.Somewhere in the network: Admission Control 3.At switches: Classification, Scheduling 4.Between hosts and routers: Signaling FlowSpec (TSpec,RSpec) Distributed Weighted Fair Queuing or other rate-based algorithm RSVP in IntServ

16 © Jörg Liebeherr, 1998-2002 16 Resource ReSerVation Protocol (RSVP) RSVP is a signaling protocol that enables senders, receivers, and routers of unicast or multicast sessions to communicate with each other for setting up state to support a service –Receiver-driven Resource reservation is initiated by receivers –Unicast and multicast sessions –Soft-state: state information of RSVP must be periodically refreshed Separate mechanisms required for authorization, authentication, and charging

17 © Jörg Liebeherr, 1998-2002 17 RSVP Functional Diagram ApplicationRSVPD Admissions Control Packet Classifier Packet Scheduler Policy Control DATADATA DATA RSVPD Policy Control Admissions Control Packet Classifier DATA Routing Process HostRouter Source: Gordon Chaffee, UC Berkeley Packet Scheduler

18 © Jörg Liebeherr, 1998-2002 18 Resource Reservation Senders advertise using PATH message Receivers reserve using RESV message –Flowspec + filterspec + policy data –Travels upstream in reverse direction of Path message Merging of reservations Sender/receiver notified of changes Source: Gordon Chaffee, UC Berkeley

19 © Jörg Liebeherr, 1998-2002 19 RSVP UDP Reservation (1) R4 R5 R3R2 R1 Host A 24.1.70.210 Host B 128.32.32.69 PATH 2 2. The Host A RSVP daemon generates a PATH message that is sent to the next hop RSVP router, R1, in the direction of the session address, 128.32.32.69. PATH 3 3. The PATH message follows the next hop path through R5 and R4 until it gets to Host B. Each router on the path creates soft session state with the reservation parameters. 1. An application on Host A creates a session, 128.32.32.69/4078, by communicating with the RSVP daemon on Host A. 1 Source: Gordon Chaffee, UC Berkeley

20 © Jörg Liebeherr, 1998-2002 20 RSVP UDP Reservation (2) R4 R5 R3R2 R1 Host A 24.1.70.210 Host B 128.32.32.69 PATH RESV 5 5. The Host B RSVP daemon generates a RESV message that is sent to the next hop RSVP router, R4, in the direction of the source address, 24.1.70.210. RESV 6 6. The RESV message continues to follow the next hop path through R5 and R1 until it gets to Host A. Each router on the path makes a resource reservation. 4. An application on Host B communicates with the local RSVP daemon and asks for a reservation in session 128.32.32.69/4078. The daemon checks for and finds existing session state. 4 Source: Gordon Chaffee, UC Berkeley

21 © Jörg Liebeherr, 1998-2002 21 RSVP Flowspecs Peak Data Rate [p] Minimum Policed Unit [m] Maximum Policed Unit [M] Token Bucket Rate [r]... Token Bucket Size [b] Sender TSpec, Controlled Load Flowspec Peak Data Rate [p] Minimum Policed Unit [m] Maximum Policed Unit [M] Token Bucket Rate [r]... Token Bucket Size [b] Guaranteed Flowspec Rate [R] Slack Term [S] Source: Gordon Chaffee, UC Berkeley

22 © Jörg Liebeherr, 1998-2002 22 Reservation Merging Receiver #1 Receiver #2 Receiver #3 Reservations merge as they travel up tree. R6 R3 R1 R4 R7 (1) 50Kbs (2) 50Kbs (3) 50Kbs (4) 100 Kbs (5) 100 Kbs (6) 100 Kbs (7) 100 Kbs (8) 60Kbs (9) 60Kbs Source: Gordon Chaffee, UC Berkeley

23 © Jörg Liebeherr, 1998-2002 23 Summary of IntServ –Advantages: Strong guarantees (bounded delays) –Disadvantages: Requires that all routers implement IntServ Scalability concerns since routers must maintain state information Charging and authentication of reservations must be solved Interdomain issues are difficult to resolve

24 © Jörg Liebeherr, 1998-2002 24 DiffServ Motivation: –The Integrated Services (IntServ) model is not scalable since it requires per-flow state in each nodeGoal: Push complexity to the network edge and keep network core simple Avoid per-flow state within the network as much as possible

25 © Jörg Liebeherr, 1998-2002 25 Differentiated Service Mechanisms Definitions :Definitions : –Mechanisms that allow providers to allocate different levels of service to different users of the Internet –broad view: –broad view: Any mechanism that treats different users differently, including signaling (RSVP), per-session scheduling, etc. –Internet context: –Internet context: Simple and lightweight mechanisms that do not depend entirely on per-flow reservation

26 © Jörg Liebeherr, 1998-2002 26 Components of Differentiated Services Service profile (1) Service profile between user and network defines commitment of the network to the user policed at the network entrance (2)Aggregate traffic from each user is policed at the network entrance according to profile Node behavior: (3) Node behavior: network nodes implement a variety of forwarding, scheduling, buffer management techniques Bits in packet header (4)Bits in packet header trigger action at nodes

27 © Jörg Liebeherr, 1998-2002 27 Common to Most Proposed Services Traffic marking (in-profile, out-profile) and enforcement is done only at network boundaries Inside the network: Only differentiate a few service classes, based on marking of the packets

28 © Jörg Liebeherr, 1998-2002 28 Policing, shaping, or marking based on profile Policing, shaping, or marking based on profile Operational Model Host Meters ISP 2 Host ISP 1 Source negotiates a traffic profile Source negotiates a traffic profile network boundary Nodes perform scheduling and buffer management based on marking of packets (“per-hop behavior”) Nodes perform scheduling and buffer management based on marking of packets (“per-hop behavior”) network boundary Policing, shaping, or marking based on profile

29 © Jörg Liebeherr, 1998-2002 29 Aspects of a Differentiated Service Semantics of the service: (1) Semantics of the service: Which service is given to in-profile traffic of a user? Spatial Granularity: (2)Spatial Granularity: Is the profile applied to a single destination, a subset of destinations, or all destinations? Assurance Level: (3) Assurance Level: What is the level of certainty that an in-profile packet will be delivered?

30 © Jörg Liebeherr, 1998-2002 30 DiffServ Services Two services defined: Assured Forwarding (AF)Assured Forwarding (AF) –customers sign service agreements with ISPs –Edge routers mark packets as being “in” or “out” of profile –core routers run RIO: RED with in/out –Distinguishes different classes: Expedited Forwarding(EF)Expedited Forwarding(EF) –Hard guarantee on the delay and delay variations

31 © Jörg Liebeherr, 1998-2002 31 Assured Forwarding - 1 User defines traffic profile (token bucket) Profile meter at network entrance tag packets as in-profile or out-profile Service guarantee:In-profile packets are unlikely to be droppedService guarantee: In-profile packets are unlikely to be dropped Out-profile packets have higher drop preference at routers Profile meter “in” “out”

32 © Jörg Liebeherr, 1998-2002 32 Assured Forwarding - 2 Mechanisms Mechanisms Needed : –Dropping Mechanisms at routers –Mechanism for tagging packets (“Meters”) –Method to classify packets Host Meters ISP 2 Host ISP 1 drop

33 © Jörg Liebeherr, 1998-2002 33 Assured Forwarding - 3 RIO Routers have different dropping mechanism: RIO = RED with `in’ and `out’ Routers do not perform separate queueing RED (Random Early Detection): When the avgerage queue size exceeds a threshold drop each packet with a certain probability (P drop ) P(drop) 1 Min_inMax_in P max_in P(drop) 1 Min_out Max_out P max_out Avg. queue

34 © Jörg Liebeherr, 1998-2002 34 Expedited Forwarding - 1 EF traffic must be served at a configured rate of R or faster, independent of the load Service is equivalent to a “virtual leased line” Routers have two priority levels (premium and best effort) Admission Control via Bandwidth Brokers Spaced to peak rate R P-bit marking

35 © Jörg Liebeherr, 1998-2002 35 Expedited Forwarding - - 2 Admission Control “Bandwidth Brokers” perform admission control at ingress router Only the ingress router differentiates flows Host Packet Marking ISP 1 Packet Marking ISP 2 dest Host Bandwidth broker Bandwidth broker

36 © Jörg Liebeherr, 1998-2002 36 Summary of DiffServ –Advantages: No per-flow processing in network core Per-flow processing only at the network edge Simpler to implement than IntServ No signaling protocol –Disadvantages: AF has weaker service guarantees EF service raises same issues with charging and authentication as IntServ services

37 © Jörg Liebeherr, 1998-2002 37 Leaf Router: Input (Leaf router = the router closest to the source)

38 © Jörg Liebeherr, 1998-2002 38 Border Router: Input (Border router = ingress router of a network)

39 © Jörg Liebeherr, 1998-2002 39 Router: Output


Download ppt "© Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet."

Similar presentations


Ads by Google