Integrated Services & RSVP

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

2. 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).

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

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

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

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

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

8. 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)

9. 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)

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