1

15-441 Computer Networking

Intserv, Diffserv, RSVP

Lecture 22: 11/20/2001 2

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?

Lecture 22: 11/20/2001 3

Application Types

• Elastic 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

Lecture 22: 11/20/2001 4

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 in Progress includes RSVP, Differentiated Services, and Integrated Services.

Lecture 22: 11/20/2001 5

Overview

• Principles for QoS• Integrated Services (Intserv)• Differentiated Services (Diffserv)• Resource ReSerVation Protocol (RSVP)

Lecture 22: 11/20/2001 6

Principles for QOS Guarantees

• Simple model for sharing and congestion studies (“dumbell topology”):

Lecture 22: 11/20/2001 7

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.

Lecture 22: 11/20/2001 8

Principles for QOS Guarantees (more)• 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:

Lecture 22: 11/20/2001 9

Principles for QOS Guarantees (more)• 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.

Lecture 22: 11/20/2001 10

Principles for QOS Guarantees (more)• 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 .

Lecture 22: 11/20/2001 11

Summary

Lecture 22: 11/20/2001 12

A Short History of Internet QoS

• Lots of initial research in the late 80s and early 90s.

• Often takes a telecommunications view of the network.

• ATM QoS and Integrated services were developed based on these results.

• Focus on per-flow, hard QoS.• Effort was driven by perceived application needs.

• In the last 5 years, the focus has shifted towards Differentiated services.

• Focus is on QoS for flow aggregates, e.g., all the flows belonging to one customer.

Lecture 22: 11/20/2001 13

Overview

• Motivation for QoS• Integrated Services (Intserv)• Differentiated Services (Diffserv)• Resource ReSerVation Protocol (RSVP)

Lecture 22: 11/20/2001 14

IETF Intserv

• Focus on per-flow QoS.• Support specific applications such as video

streaming.• Based on mathematical guarantees.

• Many concerns:• Complexity• Scalability• Business model• Charging

Lecture 22: 11/20/2001 15

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?

Lecture 22: 11/20/2001 16

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)

• The set of services that is supported on a specific network can be viewed as a service model.

• Model that can be used to select a service• E.g., cost versus performance tradeoffs

• Network architecture that supports the set of services• Considers interactions between services

Lecture 22: 11/20/2001 17

Service Models

• Guaranteed service• Targets hard real-time applications.• User specifies traffic characteristics and a service requirement.• Requires admission control at each of the routers.• Can mathematically guarantee bandwidth, delay, and jitter.

• Controlled load.• 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.

• Best effort

Lecture 22: 11/20/2001 18

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.

Lecture 22: 11/20/2001 19

Packet scheduling

• Guaranteed service• Use token bucket filter to characterize traffic

• Described by rate r and bucket depth b

• Use WFQ at the routers• Parekh’s bound for worst case queuing delay = b/r

Lecture 22: 11/20/2001 20

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.

Lecture 22: 11/20/2001 21

Overview

• Motivation for QoS• Integrated Services (Intserv)• Differentiated Services (Diffserv)• Resource ReSerVation Protocol (RSVP)

Lecture 22: 11/20/2001 22

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

Lecture 22: 11/20/2001 23

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

Lecture 22: 11/20/2001 24

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.

Lecture 22: 11/20/2001 25

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.

Lecture 22: 11/20/2001 26

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.

Lecture 22: 11/20/2001 27

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!

Lecture 22: 11/20/2001 28

Forwarding (PHB)

• PHB result in a different observable (measurable) forwarding performance behavior.

• 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.

Lecture 22: 11/20/2001 29

Forwarding (PHB)

• Expedited Forwarding (EF):• Guarantees a certain minimum rate for the EF traffic.• 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.• Possible service: providing a virtual wire.

Lecture 22: 11/20/2001 30

Forwarding (PHB)

• Assured Forwarding (AF): • 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.

• Lots of studies on how these classes and drop priorities interact with TCP flow control.

• Non-conformant traffic is remarked.

Lecture 22: 11/20/2001 31

Example of EF: A Virtual Leased Line Service

• Service offers users a dedicated traffic pipe.• Guaranteed bandwidth between two points.• Very low latency and jitter since there should be no

queuing delay (peak rate allocation).

• Admission control makes sure that all links in the network core have sufficient EF bandwidth.

• Simple case: sum of all virtual link bandwidth is less than the capacity of the slowest link.

• Traffic enforcement for EF traffic limits how much EF traffic enters the network.

Lecture 22: 11/20/2001 32

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.

Lecture 22: 11/20/2001 33

Overview

• Motivation for QoS• Integrated Services (Intserv)• Differentiated Services (Diffserv)• Resource ReSerVation Protocol (RSVP)

Lecture 22: 11/20/2001 34

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?

Lecture 22: 11/20/2001 35

Role of RSVP

• Rides on top of unicast/multicast routing protocols.

• Must be present at sender(s), receiver(s), and routers.

• Carries resource requests all the way through the network.

• At each hop consults admission control and sets up reservation. Informs requester if failure.

Lecture 22: 11/20/2001 36

Reservation Protocol: RSVP

Upper layer protocols and applications

IP

Link layer modules

ICMP IGMP RSVP

IP service interface

Link layer service interface

Lecture 22: 11/20/2001 37

RSVP Goals

• Used on connectionless networks.• Should not replicate routing functionality.• Should co-exist with route changes.

• Support for multicast.• Different receivers have different capabilities and want different QOS.• Changes in group membership should not be expensive.• Reservations should be aggregate – I.e. each receiver in group should not

have to reserve.• Should be able to switch allocated resource to different senders.

• Limit control overhead.• Modular design – should be generic “signaling” protocol.• Result:

• Receiver-oriented• Soft-state

Lecture 22: 11/20/2001 38

Receiver-Initiated Reservation

• Receiver initiates reservation by sending a reservation over the sink tree.

• Assumes multicast tree has been set up previously.• Also uses receiver-initiated mechanism.

• Hooks up with the reserved part of the tree.• How far the request has to travel to the source depends on the

level of service requested.• Uses existing routing protocol, but routers have to store the sink

tree (reverse path from forwarding path).

• Properties:• Scales well: can have parallel independent connect and

disconnect actions – single shared resource required.• Supports receiver heterogeneity: reservation specifies receiver

requirements and capabilities.

Lecture 22: 11/20/2001 39

Soft State

• Routers keep state about reservation.• Periodic messages refresh state.• Non-refreshed state times out automatically.• Alternative: Hard state

• No periodic refresh messages.• State is guaranteed to be there.• State is kept till explicit removal.• Why could there be a problem?

• Properties of soft state:• Adapts to changes in routes, sources, and receivers.• Recovers from failures• Cleans up state after receivers drop outs

• Philosophy: reservation is an optimization.

Lecture 22: 11/20/2001 40

RSVP Service Model

• Make reservations for simplex data streams.• Receiver decides whether to make reservation

• Control messages in IP datagrams (proto #46).

• PATH/RESV messages sent periodically to refresh soft state.

• One pass:• Failed requests return error messages - receiver must

try again.• No end to end ack for success.

Lecture 22: 11/20/2001 41

Basic Message Types

• PATH message• RESV message• CONFIRMATION message

• Generated only upon request.• Unicast to receiver when RESV reaches node with

established state.

• TEARDOWN message• ERROR message (if PATH or RESV fails)

Lecture 22: 11/20/2001 42

PATH Messages

• PATH messages carry sender’s T-spec.• Token bucket parameters

• Routers note the direction PATH messages arrived and set up reverse path to sender.

• Receivers send RESV messages that follow reverse path and setup reservations.

• If reservation cannot be made, user gets an error.

Lecture 22: 11/20/2001 43

RESV Messages

• RESV messages carry receiver’s R-spec.• 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?• Reservation style.

• Router performs admission control and reserves resources.

Lecture 22: 11/20/2001 44

Router Handling of RESV Messages

• If new request rejected, send error message.• If admitted:

• Install packet filter into forwarding dbase.• Pass flow parameters to scheduler.• Activate packet policing if needed.• Forward RESV message upstream.

Lecture 22: 11/20/2001 45

RSVP reservations

• Reservations from multiple receivers for a single sender are merged together at branching points.

• Reservations for multiple senders may be added up:

• Video conference

• Reservations for multiple senders may not be added up:

• Audio conference, not many talk at same time.• Only subset of speakers (filters).

Lecture 22: 11/20/2001 46

Reservation Styles

• Three styles• Wildcard/No filter – does not specify a particular sender

for group.• Fixed filter – sender explicitly specified for a

reservation.• Video conference

• Dynamic filter – valid senders may be changed over time.

• Audio conference

Lecture 22: 11/20/2001 47

Example

• Senders S1, S1, S3• Receivers R1, R2, R3• Router interfaces A,B,C,C

S1A

S2, S3B

CR1

D R2

R3

Lecture 22: 11/20/2001 48

Wildcard Filter Reservation

• R1, R2, and R3 want to reserve 4b, 3b, and 2b, respectively (b is given rate).

S1A

S2, S3B

CR1

D R2

R3

4b

3b

4b

4b

Lecture 22: 11/20/2001 49

Fixed Filter Reservation

• R1 wants to reserve 4b for S1 and 5b for S2.• R2 wants to reserve 3b for S1 and b for S3.• R3 wants to reserve b for S1.

S1A

S2, S3B

CR1

D R2

R3

S1:4bS2:5b

S1:3bS3:b

S1:4b

S2:5bS3:b

Lecture 22: 11/20/2001 50

Dynamic Filter Reservation

• R1 wants to reserve b for S1 and S2 (shared).• R2 wants to reserve 3b for S1 and S3 (shared).• R3 wants to reserve 2b for S2.

S1A

S2, S3B

CR1

D R2

R3

(S1,S2):b

(S1,S2,S3):3b

S1:3b

(S2,S3):3b

Lecture 22: 11/20/2001 51

Changing Reservation

• Receiver-oriented approach and soft state make it easy to modify reservation.

• Modification sent with periodic refresh.

Lecture 22: 11/20/2001 52

Routing Changes

• Routing protocol makes routing changes.• In absence of route or membership changes,

periodic PATH and RESV messages refresh established reservation state.

• When change, new PATH messages follow new path, new RESV messages set reservation.

• Non-refreshed state times out automatically.

Lecture 22: 11/20/2001 53

State in Switches

• Have to keep sink tree information.• No such thing as inverse multicast routing.

• Also have to keep information on sources if filters are used.

• Selected in path message.• Used in aggregation and propagating information to switches.

• Also used in limiting protocol overhead.• Switches do not propagate periodic reservation and path

messages.• They periodically regenerate copies that summarize the

information they have.

• Raises concerns about scalability.

Lecture 22: 11/20/2001 54

RSVP - Review

• Concentration on multicast may have been wrong idea.

• Unicast considered as special case of multicast.

• Receiver initiation – handle negotiation at application level.

• Receiver heterogeneity – how can low-capability receiver benefit from video sent at high bandwidth?

• Layered encoding

• Soft state• Hard state works in telephony network