Integrated Services & RSVP Types of pplications Basic approach in IntServ Key components Service models

Application types: –Elastic applications “old-fashioned” applications –Tolerant playback applications. One-way video streaming, one-way broadcast Delay and delay jitter (Figure 2.1) Removing jitter with play-out buffer (Figure 2.2) Latency.vs. fidelity –Intolerant playback applications: data need to be delievered in real-time Two way conversations (stringent delay constraint).

Design objective of IntServ: –Preserve datagram model of IP networks –Support resource reservation and QoS guarantees for multimedia applications Protect multimedia traffic from being affected by regular TCP traffic and vice verse Basic approach: similar to tele. Networks –Before sending, sender describes the traffic and resource requirement and sends the request to the network. –The request goes through the network hop-by-hop, each hop will check its resources to decide whether to reject or accept the request. –If everyone says ok, the sender will be notified and can start send data along the reserved path.

Key components in IntServ (Figure 2.4): –Control plane: QoS routing agent (QoS routing) –Can be difficult. Admission control Reservation setup agent (RSVP) Resource reservation table –Data plane: Flow identification Packet scheduler

Admission control –To decide whether to accept a new request (done at each router in IntServ). –Parameter based A set of parameters is used to characterize traffic flows. The admission control agent computes the required resources based on the parameters. Difficult to model the traffic. –Measurement based Measure the actual traffic load for admission control. Probabilistic in nature, no hard guarantees. Trade-off between resource guarantees and resource utilizations. –Common algorithms: simple sum, measured sum, acceptance region, equivalent bandwidth.

Flow Identifications: –Identify to which flow a packet belong to –An IP flow is identified by five fields: source IP address, destination IP address, source port, destination port, protocol ID – five-tuple –The flow identification agent must compare the five- tuple of a packets to all five tuples in the reservation table. –Requres fast hardware if performed at wire speed 64 byte packets arrive in a 622Mbps line back to back in less than 1us.

Service Models: –What users can ask and what commitments the network can commit. –Flow model in IntServ Described by a leaky bucket –Token rate ( r ) : 1bps – 40tbps –Token-bucket depth (b): 1 B to 250GB –Peak traffic rate (p): 1bps – 40tbps –Minimum policed unit (m): packets of size < m bytes will be counted as m bytes. –Maximum packet size (M): What is leaky bucket? –Guaranteed Service and Controlled load Service

Guaranteed Service (RFC 2212) –For applications requiring fixed delay bound and a bandwidth guarantee –Control the maximum queuing delay –Guarantees that packets will arrive within a certain time and will not be discarded because of queue overflows –No control on minimal or average delay (what about jitter?) –No packet fragmentation is allowed. –Guaranteed service is invoked by a sender specifying a traffic descriptor (Tspec) and a service specification (Rspec) Rspec has two parameters: Service rate ( R ) and Slack Term ( S)

–Worst case queuing delay for guaranteed service: ((b-M)(p-R)) / (R (p-r)) + (M+Ctot)/R + Dtot if p>R>=r (M+Ctot) / R + Dtot if (R >=p >= r)

Controlled load service (RFC 2211) –Provides unloaded network conditions Closely approximates traditional best-effort in a lightly loaded or unloaded network environment –Intended for adaptive applications –Priority service with admission control –No fragmentation, packets must comply to MTU