Integrated Services & RSVP
Download
Report
Transcript Integrated Services & RSVP
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 fivetuple 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