Download lec 3 - handout3

15-441 Computer Networking
Intserv, Diffserv, RSVP
1
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?
2
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
3
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.
4
Overview
•
•
•
•
Principles for QoS
Integrated Services (Intserv)
Differentiated Services (Diffserv)
Resource ReSerVation Protocol (RSVP)
5
Principles for QOS Guarantees
• Simple model for sharing and congestion studies
(“dumbell topology”):
6
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.
7
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:
8
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.
9
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 .
10
Summary
11
Overview
•
•
•
•
Motivation for QoS
Integrated Services (Intserv)
Differentiated Services (Diffserv)
Resource ReSerVation Protocol (RSVP)
12
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
13
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?
14
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
15
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
16
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 Tspec to the routers where reservation is required; RSVP is
a leading candidate for such signaling protocol.
17
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
18
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.
19
Overview
•
•
•
•
Motivation for QoS
Integrated Services (Intserv)
Differentiated Services (Diffserv)
Resource ReSerVation Protocol (RSVP)
20
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
21
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
22
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.
23
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.
24
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.
25
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!
26
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.
27
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.
28
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.
29
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.
30
Reservation Protocol: RSVP
Upper layer protocols and applications
IP service interface
IP
ICMP IGMP RSVP
Link layer service interface
Link layer modules
31
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
32
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.
33
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.
34
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.
35
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)
36
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.
37
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.
38
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.
39
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).
40
Reservation Styles: 3 styles
• Wildcard/No filter – does not specify a particular
sender for group.
• Creates a single reservation shared by flows from all
upstream senders belonging to the unicast
(multicast) session.
• The reservation propagates towards ALL sender
hosts and automatically extend to new senders as
they appear.
41
Reservation Styles
• Fixed filter – sender explicitly specified for a
reservation.
• Video conference
• Creates distinct reservations for data packets from a
particular sender, not sharing them with other sender’
packets for the same session.
• Dynamic filter / Shared-Explicit– valid senders may be
changed over time.
• Audio conference
• Creates a single reservation shared by selected
upstream senders.
• Allows a receiver to explicitly specify the set of senders to
be included.
42
RSVP Reservation Styles
Reservations
Sender
Selection
Explicit
Wildcard
Distinct
Fixed Filter
None
Shared
Shared Explicit
Wildcard
Filter
•Shared reservations (WF and SE) are appropriate for multicast
applications in which multiple sources are unlikely to transmit
simultaneously (packetized audio for example).
•FF style makes separate reservations for each sender, and is
appropriate for video applications.
43
Example
A
S1
B
S2, S3
C
D
R1
R2
R3
• Senders S1, S1, S3
• Receivers R1, R2, R3
• Router interfaces A,B,C,D
44
Wildcard Filter Reservation
• R1, R2, and R3 want to reserve 4b, 3b, and 2b,
respectively (b is given rate).
4b
A
S1
4b
S2, S3
B
C
4b
R1
D
R2
3b
R3
45
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.
S1:4b A
S1
B
S2, S3
S2:5b
S3:b
C
S1:4b
S2:5b
R1
D
R2
S1:3b
S3:b
R3
46
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.
S1:3b A
S1
B
S2, S3
(S2,S3):3b
C
(S1,S2):b
R1
D
R2
(S1,S2,S3):3b
R3
47
Reservations in action - FF
48
Reservations in action – WF
49
Reservations in action - SE
50
Changing Reservation
• Receiver-oriented approach and soft state make it
easy to modify reservation.
• Modification sent with periodic refresh.
51
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.
52