IP Quality of Service.

IP Quality of Service

Motivation Internet currently provides only single class of “best-effort” service. No admission control and no assurances about delivery Existing applications are elastic. Tolerate delays and losses Can adapt to congestion Future “real-time” applications may be inelastic. Should we modify these applications to be more adaptive or should we modify the Internet to support inelastic behavior?

Application Types Elastic applications. Continuous media applications.
Wide range of acceptable rates, although faster is better E.g., data transfers such as FTP Continuous media applications. Lower and upper limit on acceptable performance Sometimes called “tolerant real-time” since they can adapt to the performance of the network E.g., changing frame rate of video stream “Network-aware” applications Hard real-time applications. Require hard limits on performance – “intolerant real-time” E.g., control applications

QoS Defined The goal : Fundamental principle
Provide some level of predictability and control beyond the current IP “best-effort” service Fundamental principle Leave complexity at the “edges” and keep network “core” simple

QoS Metrics Performance attributes
Service availability Delay Delay variation (jitter) Throughput Packet loss rate Vary according to Service Level Agreement (SLA)

Service Level Agreements (SLA)

What is the problem? Solutions
Different applications have different delay, bandwidth, and jitter needs Some applications are very sensitive to changing network conditions: the packet arrival time distribution is important Solutions Make applications adaptive Build more flexibility into network

QoS’s Quest The Holy Grail of computer networking is to design a network that has the flexibility and low cost of the Internet, yet offers the end-to-end quality-of-service guarantees of the telephone network. --S. Keshav

Improving QOS in IP Networks
IETF groups are working on proposals to provide better QOS control in IP networks, i.e., going beyond best effort to provide some assurance for QOS. Work includes RSVP, Differentiated Services, and Integrated Services.

Overview Principles for QoS Integrated Services (Intserv)
Differentiated Services (Diffserv)

Principles for QOS Guarantees
Simple model for sharing and congestion studies (“dumbell topology”):

Principles for QOS Guarantees (more)
Consider a phone application at 1Mbps and an FTP application sharing a 1.5 Mbps link. Bursts of FTP can congest the router and cause audio packets to be dropped. Want to give priority to audio over FTP. PRINCIPLE 1: Marking of packets is needed for router to distinguish between different classes; and new router policy to treat packets accordingly.

Applications misbehave (audio sends packets at a rate higher than 1Mbps assumed above). PRINCIPLE 2: provide protection (isolation) for one class from other classes. Require Policing Mechanisms to ensure sources adhere to bandwidth requirements; Marking and Policing need to be done at the edges:

Alternative to Marking and Policing: allocate a set portion of bandwidth to each application flow; can lead to inefficient use of bandwidth if one of the flows does not use its allocation. PRINCIPLE 3: While providing isolation, it is desirable to use resources as efficiently as possible.

Cannot support traffic beyond link capacity. PRINCIPLE 4: Need a Call Admission Process; application flow declares its needs, network may block call if it cannot satisfy the needs .

Summary

Overview Motivation for QoS Integrated Services (Intserv)

IETF Intserv Focus on per-flow QoS. What is a flow?
Support specific applications such as video streaming. What is a flow? Equivalent packets by some classification RSVP: Set of packets traversing a network element that are all covered by the same QoS request Packet classifier determines which packets belong to which flows IPv6 includes a flow label to ease classification ISP usage (UUNET) Microflow: TCP or similar bandwidth connection Macroflow: Large aggregates of packets flowing between two superhubs

Because the Intserv model provides per-flow reservations, each flow is assigned a flow descriptor.
The flow descriptor defines the traffic and QoS characteristics for a specific flow of data packets. The flow descriptor consists of a filter specification (filterspec) and a flow specification (flowspec)

The filterspec identifies the packets that belong to a specific flow with the sender IP address and source port. The information from the filterspec is used in the packet classifier Simplest filter: Source, Dest address/port pair Data filter: classifies packets according to contents The flowspec contains a set of parameters that are called the invocation information. The invocation information divides into two groups: Traffic Specification (Tspec) Service Request Specification (Rspec)

Components of Integrated Services
Type of service model What does the network promise? Service interface How does the application describe what it wants? Packet scheduling How does the network meet promises? Establishing the guarantee How is the promise communicated to/from the network? How is admission of new applications controlled?

Service Models Network can support traffic streams with different “quality of service”. Best effort Predictive or differentiated services Strong guarantees on the level of service (real-time) Service: contract between network and communication client Three common services Best-effort (“elastic” applications) Hard real-time (“real-time” applications) Soft real-time (“tolerant” applications)

Worse-case : Guaranteed Services
Targets hard real-time applications. User specifies traffic characteristics and a service requirement. Requires admission control at each of the routers. Can guarantee bandwidth, delay, and jitter. 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

Average-case: Controlled Load Service
Targets applications that can adapt to network conditions within a certain performance window. User specifies traffic characteristics and bandwidth. Requires admission control at each of the routers. Guarantee not as strong as with the guaranteed service. e.g., measurement-based admission control. Service contract: Network to client: Average delay, jitter, bandwidth, e.g., makes network appear as an unloaded, best effort network with bandwidth and delay 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

Service Interface Session must first declare its QoS requirement and characterize the traffic it will send through the network R-spec: defines the QoS being requested by receiver (e.g., rate r) T-spec: defines the traffic characteristics of sender (e.g., leaky bucket with rate r and buffer size b). A signaling protocol is needed to carry the R-spec and T-spec to the routers where reservation is required; RSVP is a leading candidate for such signaling protocol.

Once a connection is accepted, the host must use only the amount of resources reserved. It may not use more than that. What if the host is malicious and attempts to use more network resources than it reserved? It where Leaky Bucket comes to play

Leaky Bucket Used in conjunction with resource reservation to police the host’s reservation At the host-network interface, allow packets into the network at a constant rate Packets may be generated in a bursty manner, but after they pass through the leaky bucket, they enter the network evenly spaced

Leaky Bucket: Analogy

The leaky bucket is a “traffic shaper”: It changes the characteristics of packet stream
Traffic shaping makes more manageable and more predictable Usually the network tells the leaky bucket the rate at which it may send packets when the connection begins Polices the average rate

Leaky Bucket doesn’t allow bursty transmissions
In some cases, we may want to allow short bursts of packets to enter the network without smoothing them out For this purpose we use a token bucket, which is a modified leaky bucket

Token Bucket The bucket holds tokens instead of packets
Tokens are generated and placed into the token bucket at a constant rate When a packet arrives at the token bucket, it is transmitted if there is a token available. Otherwise it is buffered until a token becomes available. The token bucket has a fixed size, so when it becomes full, subsequently generated tokens are discarded

Token Bucket vs. Leaky Bucket
Case 1: Short burst arrivals

Case 2: Large burst arrivals

Flow Specification: Token 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

Packet Scheduling Implemented in hosts/routers to control link allocation Queuing algorithms Weighted Fair Queuing (WFQ) Class Based Queuing (CBQ) Queue management Random Early Detection (RED)

Weighted Fair Queuing (WFQ)
Traffic placed into queues according to flow specification, flow filter Fair queuing Implements fairness of bit by bit scheduling on a per packet basis Gives queues a fair share of total bandwidth Weighted Queue are not weighted evenly for scheduling Proven: adequate for Guaranteed Service

Class Based Queuing (CBQ) Combines scheduling and link sharing
Hierarchical link sharing Hierarchical queues Enables protocol, organization isolation Scheduling Does not define a particular scheduling algorithm General scheduler for low latency when no congestion Link-sharing policing scheduler when congested Scheduling per hierarchy

CBQ Example

Random Early Detection (RED)
Queue management algorithm for congestion control This is a proactive approach in which the router discards one or more packets before the buffer becomes completely full. Each time a packet arrives, the RED algorithm computes the average queue length, avg. If avg is lower than some lower threshold, congestion is assumed to be minimal or non-existent and the packet is queued

If avg is greater than some upper threshold, congestion is assumed to be serious and the packet is discarded. If avg is between the two thresholds, this might indicate the onset of congestion. The probability of congestion is then calculated.

Call Admission Call Admission: routers will admit calls based on their R-spec and T-spec and base on the current resource allocated at the routers to other calls.

The Integrated Service model
Integrated Services use the Resource Reservation Protocol (RSVP) for the signalling of the reservation messages

Resource Reservation Model
Senders advertise using flowspecs RSVP daemons forward advertisements to receivers, update available bandwidth, minimum delay Receivers reservations use flowspec, filterspec combination (flow descriptor) Sender/receiver notified of changes Reservations are merged in multicast case

Role of RSVP Signaling protocol for establishing per flow state
Carry resource requests from hosts to routers Collect needed information from routers to hosts At each hop Consult admission control and policy module Set up admission state or informs the requester of failure

Integrated Services Example: Data Path
Per-flow classification Receiver Sender 47

Integrated Services Example: Data Path
Per-flow buffer management Receiver Sender 48

Integrated Services Example
Per-flow scheduling Receiver Sender 49

How Things Fit Together

RSVP Reservation Model
Performs signaling to set up reservation state for a session A session is a simplex data flow sent to a unicast or a multicast address, characterized by <IP dest, protocol number, port number> Multiple senders and receivers can be in session

RSVP terminology Flow descriptor (Flow spec + Filter Spec)
Flow spec (Rate, max burst) Sender can Explicitly specify flow spec or not specify Filter Spec (Sender address, TCP/UDP, Port#) Aids in combining similar flows Filter can be shared (SE-style) or can use wild cards (all senders on a given port or a given sender on all ports, etc) The style may be shared or distinct in a sense that all reservations may be handled as one single reservation or there may be a single reservation for each upstream sender respectively.

The Big Picture

RSVP Basic Operations Sender: sends PATH message via the data delivery path Set up the path state each router including the address of previous hop Receiver sends RESV message on the reverse path Specifies the reservation style, QoS desired Set up the reservation state at each router Things to notice Receiver initiated reservation Decouple routing from reservation Two types of state: path and reservation

RSVP messages PATH message – sets up state along path followed by packets RESV message – request for reservation back along setup path path PATH_TEAR, RESV_TEAR, RESV_CONFIRM, RESV_ERROR, PATH_ERROR

RSVP Operation

RSVP PATH MESSAGE From sender to receiver (unicast or multicast)
Intercepted at each RSVP aware hop Includes Sender TSpec : Traffic characteristics of the sender Token bucket rate, depth, max flow rate, max packet size forms one side of the ``contract'' between the data flow and the service. F-flag: specify whether filtered reservation is allowed Routers store: Path state, i.e., PHOP address to previous hop (RSVP aware node) If F-flag is set, store sender and its flowspec Otherwise, just add new link to multicast tree

RSVP RESV MESSAGE RESV messages processing at each hop
From receiver to sender(s) to reserve resources Sent hop-by-hop using PHOP information Reservation style and flow description Reservation style (FF,SE, WF) Fixed-filter, Shared-explicit, wildcard-filter Senders to which the reservation applies Rspec, QoS specific requirements RSpec is highly specific to the service required, and may include information like bandwidth allocation, maximum delay, or packet loss probabilities etc. RESV messages processing at each hop Merging of RESV messages Forwards resv messages using PHOP

(3) 50Kbs (7) 100 Kbs (6) 100 Kbs (2) 50Kbs (5) 100 Kbs (9) 60Kbs
Reservations merge as they travel up tree. Issue: who pays for service, how much? Merging different types of flows Flow 1: Low delay, low bandwidth Flow 2: High delay, high bandwidth Flow with low delay, high bandwidth satisfies Flows 1 and 2, but it may cost much more than Flow 1 or 2. Only certain flows can be easily merged given price constraints (3) 50Kbs (7) 100 Kbs R1 (6) 100 Kbs R3 (2) 50Kbs (5) 100 Kbs (9) 60Kbs R4 R6 R7 (1) 50Kbs (8) 60Kbs (4) 100 Kbs Receiver #1 Receiver #2 Receiver #3

RSVP UDP Reservation: an example (1)
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, R4 PATH 1. An application on Host A creates a session, /4078, by communicating with the RSVP daemon on Host A. 1 R1 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. PATH Host B Host A R5

RSVP UDP Reservation: an example (2)
PATH 4. An application on Host B communicates with the local RSVP daemon and asks for a reservation in session /4078. The daemon checks for and finds existing session state. 4 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, PATH R1 Host B RESV PATH PATH Host A 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. RESV R5

RSVP Routing Problems Routing is separated from admission control
If route changes, reservation must be made along new route New reservation takes time to setup New reservation might fail Old route could still be working fine

Route Pinning Problem: asymmetric routes
You may reserve resources on RS3S5S4S1S, but data travels on SS1S2S3R ! Solution: use PATH to remember direct path from S to R, i.e., perform route pinning S2 R S S1 S3 PATH RESV IP routing S4 S5

How Is the Token Bucket Used?
Can be enforced by End-hosts (e.g., cable modems) Routers (e.g., ingress routers in a Diffserv domain) Can be used to characterize the traffic sent by an end-host

Source Traffic Characterization
Arrival curve – maximum amount of bits transmitted during an interval of time Δt Use token bucket to bound the arrival curve bps bits Arrival curve Δt time

QoS Guarantees: Per-hop Reservation
End-host: specify the arrival rate characterized by token-bucket with parameters (b,r,R) the maximum maximum admissible delay D Router: allocate bandwidth ra and buffer space Ba such that no packet is dropped no packet experiences a delay larger than D slope ra slope r bits Arrival curve b*R/(R-r) D Ba

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 provide a per-hop delay guarantee and forward RESV with updated info In simplest case routers split the delay (b,r,R,3) num hops S2 R S (b,r,R) (b,r,R,2,D-d1) (b,r,R,3,D) worst-case delay S1 S3 (b,r,R,1,D-d1-d2) (b,r,R,0,0) PATH RESV

Reservation Style Motivation: achieve more efficient resource utilization in multicast (M x N) Observation: in a video conferencing when there are M senders, only a few can be active simultaneously Multiple senders can share the same reservation Various reservation styles specify different rules for sharing among senders

Reservation Styles and Filter Spec
use filter to specify which sender can use the reservation Three styles Wildcard filter: does not specify any sender; all packets associated to a destination shares same resources Group in which there are a small number of simultaneously active senders Fixed filter: no sharing among senders, sender explicitly identified for the reservation Sources cannot be modified over time Dynamic filter: resource shared by senders that are (explicitly) specified Sources can be modified over time

Wildcard Filter Example
Receivers: H1, H2; senders: H3, H4, H5 Each sender sends B H1 reserves B; listen from one server at a time

H2 reserves B

Wildcard Filter Advantages Disadvantages Minimal state at routers
Routers need to maintain only routing state augmented by reserved bandwidth on outgoing links Disadvantages May result in inefficient resource utilization

Wildcard Filter: Inefficient Resource Utilization Example
H1 reserves 3B; wants to listen from all senders simultaneously Problem: reserve 3B on (S3:S2) although 2B sufficient!

Fixed Filter Example Receivers: H2, H3, H4, H5; Senders: H1, H4, H5
Routers maintain state for each receiver in the routing table

Fixed Filter Example H2 wants to receive B only from H4

Dynamic Filter Example
H5 wants to receive 2B from any source

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 Claimed advantages no need to clean up dangling state after failure can tolerate lost signaling packets signaling message need not be reliably transmitted easy to adapt to route changes State can be explicitly deleted by a Teardown message

Tear-down Example H4 leaves the group H4 no longer sends PATH message
State corresponding to H4 removed

RSVP Soft-state RSVP control messages need to be sent periodically
State will disappear if not refreshed Periodic state refresh every t sec (30 sec) If no refresh within n*t (n=3) , delete state RSVP messages sent as router-alert message Intermediate routers intercept packets and update state accordingly

Soft State (cont) 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 Claimed advantages No need to clean up dangling state after failure Can tolerate lost signaling packets Signaling message need not be reliably transmitted Easy to adapt to route changes State can be explicitly deleted by a Teardown message

RSVP and Routing RSVP designed to work with variety of routing protocols Minimal routing service RSVP asks routing how to route a PATH message Route pinning addresses QoS changes due to “avoidable” route changes while session in progress QoS routing RSVP route selection based on QoS parameters granularity of reservation and routing may differ Explicit routing Use RSVP to set up routes for reserved traffic

Recap of RSVP PATH message RESV message Other messages
sender template and traffic spec advertisement mark route for RESV message follow data path RESV message reservation request, including flow and filter spec reservation style and merging rules follow reverse data path Other messages PathTear, ResvTear, PathErr, ResvErr

Why did IntServ fail?

Goal: provide support for wide variety of applications:
Interactive TV, IP telephony, on-line gamming (distributed simulations), VPNs, etc Problem: Best-effort cannot do it? Intserv can support all these applications, but Too complex Not scalable

Will RSVP Succeed? Telcos and long-haul ISPs want constant bit-rate allocations RSVP will not control backbone allocations Need simpler mechanism such as differentiated service Microsoft, networking vendors see demand for QoS over IP RSVP is only alternative today RSVP might find a home in corporate networks

Overview Motivation for QoS Integrated Services (Intserv)

Differentiated Services
Intended to address the following difficulties with Intserv and RSVP; Scalability: maintaining states by routers in high speed networks is difficult due to the very large number of flows Flexible Service Models: Intserv has only two classes, want to provide more qualitative service classes; want to provide ‘relative’ service distinction (Platinum, Gold, Silver, …) Simpler signaling: (than RSVP) many applications and users may only want to specify a more qualitative notion of service

Diffserv - Motivation Do fine-grained enforcement only at the edge of the network. Typically slower links at edges E.g., mail sorting in post office Label packets with a field. E.g., a priority stamp The core of the network uses only the type field for QoS management. Small number of types with well defined forwarding behavior Can be handled fast Example: expedited service versus best effort Evolution rather than revolution

Diffserv - Discussion Diffserv defines an architecture and a set of forwarding behaviors. It is up to the service providers to define and implement end-to-end services on top of this architecture. Offers a more flexible service model; different providers can offer different service. One of the main motivations for Diffserv is scalability. Keep the core of the network simple. Focus of Diffserv is on supporting QoS for flow aggregates. Although architecture does not preclude more fine-grained guarantees.

Classification and marking of packets at the edge of the network makes the packets accessible to QoS handling within the network

Optimized queuing and forwarding in the core of the network (PHB-Per Hop Behavior) allows for fast efficient delivery

Edge Router/Host Functions
Classification: marks packets according to classification rules to be specified. Metering: checks whether the traffic falls within the negotiated profile. Marking: marks traffic that falls within profile. Conditioning: delays and then forwards, discards, or remarks other traffic.

Classification and Conditioning
Packet is marked in the Type of Service (TOS) in IPv4, and Traffic Class in IPv6. 6 bits used for Differentiated Service Code Point (DSCP) and determine PHB that the packet will receive. 2 bits are currently unused.

No state info to be maintained by routers!
Core Functions Forwarding: according to “Per-Hop-Behavior” or PHB specified for the particular packet class; such PHB is strictly based on class marking (no other header fields can be used to influence PHB). BIG ADVANTAGE: No state info to be maintained by routers!

Forwarding (PHB) PHB result in a different observable (measurable) forwarding performance behavior. PHBs are defined as “black box” PHB does not specify what mechanisms to use to ensure required PHB performance behavior. Examples: Class A gets x% of outgoing link bandwidth over time intervals of a specified length. Class A packets leave first before packets from class B.

Default PHB RFC2474, Definition of Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers Default PHB Good old Best-effort behavior Recommended DSCP: “000000” Note: Each PHB has a “recommended” DSCP value but ISPs can use different value in their network

Forwarding (PHB) Expedited Forwarding (EF): RFC2598
Guarantees a certain minimum rate for the EF traffic. EF PHB can be used to build a low loss, low latency, low jitter, assured bandwidth, end-to-end service Targets VoIP, Virtual Leased Lines Assured traffic sees no (or very small) queues/delay Constraint: Requires bounding rates such that, at every transit node, the aggregate’s max arrival rate is less than the aggregate min departure rate Implies isolation: guarantee for the EF traffic should not be influenced by the other traffic classes. Admitted based on peak rate. Non-conformant traffic is dropped or shaped. Recommended DSCP=101110

Forwarding (PHB) Assured Forwarding (AF): RFC2597
Assured Forwarding (AF) PHB Group is meant to offer different levels of forwarding assurances for IP packets received from a customer DS domain AF defines 4 classes with some bandwidth and buffers allocated to them. The intent is that it will be used to implement services that differ relative to each other (e.g., gold, silver,…). Within each class, there are three drop priorities, which affect which packets will get dropped first if there is congestion. Non-conformant traffic is remarked.

DS node should implement all 4 general AF classes
Currently defined 4 independently forwarded AF classes (ie 4 “queues” and 4 virtual networks with independent capacity management) Within each AF class, 3 levels of drop precedence Within each AF class, RED-like buffer mgt DS node should implement all 4 general AF classes DS node must allocate a configurable minimum amount of forwarding resources to each implemented AF class

Diff-Serv Functional Blocks
Classifier Conditioner Forwarding PHB Metering Dropping Marking Shaping Accounting Scheduling Discard Implementation Features ACL QPPB CAR TS Netflow CEF CBWFQ PQ WRED

Differentiated Services Issues
AF and EF are not even in a standard track yet… research ongoing. The key to making Diffserv work is bandwidth management in the network core. Simple for simple services such as the virtual pipe, but it is much more challenging for complex service level agreements. Notion of a “bandwidth broker” that manages the core network bandwidth. Definition of end-to-end services for paths that cross networks with different forwarding behaviors Some packets will be handled differently in different routers. Some routers are not DiffServ capable.

IP Quality of Service.

Similar presentations

Presentation on theme: "IP Quality of Service."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

IP Quality of Service.

Similar presentations

Presentation on theme: "IP Quality of Service."— Presentation transcript:

Similar presentations

About project

Feedback