15-441 Computer Networking

1
15-441 Computer Networking

• Intserv, Diffserv, RSVP

2
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?

3
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

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

5
Overview

• Principles for QoS
• Integrated Services (Intserv)
• Differentiated Services (Diffserv)
• Resource ReSerVation Protocol (RSVP)

6
Principles for QOS Guarantees

• Simple model for sharing and congestion studies
  (dumbell topology)

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

8
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

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

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

11
Summary
12
A Short History of Internet QoS

• Lots of initial research in the late 80s and
  early 90s.
• Often takes a telecommunications view of the
  network.
• ATM QoS and Integrated services were developed
  based on these results.
• Focus on per-flow, hard QoS.
• Effort was driven by perceived application needs.
• In the last 5 years, the focus has shifted
  towards Differentiated services.
• Focus is on QoS for flow aggregates, e.g., all
  the flows belonging to one customer.

13
Overview

• Motivation for QoS
• Integrated Services (Intserv)
• Differentiated Services (Diffserv)
• Resource ReSerVation Protocol (RSVP)

14
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

15
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?

16
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

17
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

18
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 T-spec to the routers where
  reservation is required RSVP is a leading
  candidate for such signaling protocol.

19
Packet scheduling

• Guaranteed service
• Use token bucket filter to characterize traffic
• Described by rate r and bucket depth b
• Use WFQ at the routers
• Parekhs bound for worst case queuing delay b/r

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

21
Overview

• Motivation for QoS
• Integrated Services (Intserv)
• Differentiated Services (Diffserv)
• Resource ReSerVation Protocol (RSVP)

22
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

23
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

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

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

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

27
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!

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

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

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

31
Example of EF A Virtual Leased Line Service

• Service offers users a dedicated traffic pipe.
• Guaranteed bandwidth between two points.
• Very low latency and jitter since there should be
  no queuing delay (peak rate allocation).
• Admission control makes sure that all links in
  the network core have sufficient EF bandwidth.
• Simple case sum of all virtual link bandwidth is
  less than the capacity of the slowest link.
• Traffic enforcement for EF traffic limits how
  much EF traffic enters the network.

32
Differentiated Services Issues

• AF and EF are not even in a standard track yet
  research ongoing.
• The key to making Diffserv work is bandwidth
  management in the network core.
• Simple for simple services such as the virtual
  pipe, but it is much more challenging for complex
  service level agreements.
• Notion of a bandwidth broker that manages the
  core network bandwidth.
• Definition of end-to-end services for paths that
  cross networks with different forwarding
  behaviors
• Some packets will be handled differently in
  different routers.
• Some routers are not DiffServ capable.

33
Overview

• Motivation for QoS
• Integrated Services (Intserv)
• Differentiated Services (Diffserv)
• Resource ReSerVation Protocol (RSVP)

34
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?

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

36
Reservation Protocol RSVP
Upper layer protocols and applications
IP service interface
IP
ICMP
IGMP
RSVP
Link layer service interface
Link layer modules
37
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

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

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

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

41
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)

42
PATH Messages

• PATH messages carry senders 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.

43
RESV Messages

• RESV messages carry receivers 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.

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

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

46
Reservation Styles

• Three styles
• Wildcard/No filter does not specify a
  particular sender for group.
• Fixed filter sender explicitly specified for a
  reservation.
• Video conference
• Dynamic filter valid senders may be changed
  over time.
• Audio conference

47
Example

• Senders S1, S1, S3
• Receivers R1, R2, R3
• Router interfaces A,B,C,C

48
Wildcard Filter Reservation

• R1, R2, and R3 want to reserve 4b, 3b, and 2b,
  respectively (b is given rate).

A
C
S1
R1
B
D
R2
S2, S3
R3
49
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.

A
C
S1
R1
B
D
R2
S2, S3
R3
50
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.

A
C
S1
R1
B
D
R2
S2, S3
R3
51
Changing Reservation

• Receiver-oriented approach and soft state make it
  easy to modify reservation.
• Modification sent with periodic refresh.

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

53
State in Switches

• Have to keep sink tree information.
• No such thing as inverse multicast routing.
• Also have to keep information on sources if
  filters are used.
• Selected in path message.
• Used in aggregation and propagating information
  to switches.
• Also used in limiting protocol overhead.
• Switches do not propagate periodic reservation
  and path messages.
• They periodically regenerate copies that
  summarize the information they have.
• Raises concerns about scalability.

54
RSVP - Review

• Concentration on multicast may have been wrong
  idea.
• Unicast considered as special case of multicast.
• Receiver initiation handle negotiation at
  application level.
• Receiver heterogeneity how can low-capability
  receiver benefit from video sent at high
  bandwidth?
• Layered encoding
• Soft state
• Hard state works in telephony network