Chapter 6 outline 6.1 Multimedia

Networking Applications 6.2 Streaming stored

audio and video RTSP

6.3 Real-time, Interactive Multimedia: Internet Phone Case Study

6.4 Protocols for Real-Time Interactive Applications RTP,RTCP SIP

6.5 Beyond Best Effort 6.6 Scheduling and

Policing Mechanisms 6.7 Integrated

Services 6.8 RSVP 6.9 Differentiated

Services

Last two lectures Principles for QoS

Leaky bucket + WFQ Guaranteed QoS (bounded delay)

How to realize them in the Internet architecture?

IETF Integrated Services

Architecture for providing QoS guarantees in IP networks for individual application sessions

Resource reservation: routers maintain state info (like a VC) of allocated resources, QoS req’s

Admit/deny new call setup requests

Question: can newly arriving flow be admitted with performance guarantees while not violated QoS guarantees made to already admitted flows?

IntServ scenario Resource reservation

traffic, QoS declaration call setup, signaling (RSVP) per-element admission control

QoS-sensitive scheduling (e.g.,

WFQ)

request/reply

Traffic characterization and QoS spec.In order to know if a router has sufficient

resources, an arriving session must: declare its QoS requirement

• R-spec: defines the QoS being requested characterize traffic it will send into network

• T-spec: defines traffic characteristics

Specific form of R-spec and T-spec depends on the requested service.

Signaling for call setup R-spec and T-spec are sent to routers (where

reservation is required) RSVP protocol does signaling, later RFC 2210

Pre-element call admission Router determines whether it can support the

new session. Depends on: T-spec R-spec Existing resource commitments made to other

sessions.

WFQ

(1)T-specR-spec

(2)

(3) Reply: whether requestCan be satisfied

RSVP signaling setup

Intserv QoS: Two service modelsGuaranteed service: [rfc2211] worst case traffic arrival: leaky-

bucket-policed source simple (mathematically

provable) bound on delay [Parekh 1992, Cruz 1988]

Controlled load service: [rfc 2212] "a quality of service closely

approximating the QoS that same flow would receive from an unloaded network element.“

No guarantee, but with high probability the packets will go through a router without excessive delay.

WFQ

token rate, r

bucket size, bper-flowrate, R

D = b/Rmax

arrivingtraffic

RSVP: signaling protocol to make reservation RSVP is present in both end-hosts and routers

Host, on behave of a flow, sends requests Routers forward requests

Implementation features: Multicast-oriented Receiver-oriented

RSVP belongs to which layer? Does it follow the principle of end-to-end augment? Application layer, or Transport layer, or Network layer

RSVP is not… a protocol to provide bandwidth

Routers decide bandwidth allocation (possibly no bandwidth)

a routing protocol The RSVP daemon consults the local routing

protocol(s) to obtain routes. RSVP is designed to operate with existing and future unicast and multicast routing protocols. A host sends IGMP messages to join a multicast group, but it uses RSVP messages to reserve resources along the delivery path(s) from that group.

RSVP functionalities RSVP handles heterogeneous receivers.

Different hosts on the same multicast delivery tree may have different capabilities and therefore need different QoS.

RSVP adapts to changing group membership as well as changing routes. For dynamic adaptability and robustness, RSVP

maintains “soft state” in the routers. The only permanent state is in the end systems, which periodically send their RSVP control messages to refresh the router state. In the absence of refresh, RSVP state in routers will time out and be deleted.

RSVP messages Path messages: RSVP sender host sends a

Path message downstream. These store the ‘path state’ in each node along the way. This path state includes the IP address of the previous hop node which is used to route the Resv message in the reverse direction. Distribute traffic source information Collect path information Install necessary state

RSVP messages Resv message: Each receiver host sends a

Resv message upstream towards the senders. These messages must follow the exact reverse path the data will use. They create and maintain the reservation state in each node along the path.

Follow the reserved path of PATH messages Specify the resource requirements Setup state in the path

Last words: scalability and Diffserv

Access AccessBackbone

Diffserv regionPer flow policingand marking

Per-classscheduling

RSVPsignaling

Trust Boundary