Transport Layer: Quality of Service

1
Transport Layer Quality of Service

• Application Requirements
• Integrated Services (RSVP)
• Differentiated Services (DIFFSERV)
• Jennifer C. Hou

2
Quality of Service

• What do we mean by quality of service?
• End-to-end delay the time it takes for packets
  to be transported from the sender to the receiver
  is below a pre-specified delay bound.
• Available bandwidth the minimum bandwidth
  available for a connection exceeds a
  pre-specified value.
• Packet loss ratio the percentage of packet loss
  is below a certain threshold.

3
Application Requirements

• New applications require deliver on time
  assurances from the network
• Applications that are sensitive to the timeliness
  of their data are called real-time applications
• Voice
• Video
• Industrial control
• Timeliness guarantees must come from inside the
  network
• End-hosts cannot correct late packets like they
  can correct for lost packets
• Need more than best-effort service
• IETF is standardizing extensions to best-effort
  model

4
Real-Time Applications

• Two types or applications
• Hard real-time
• Elastic (soft real-time)
• Example real-time application requirements -
  audio
• Sample voice once every 125?s
• Each packet has a playback time
• Packets experience variable delay in network
• Add constant factor to playback time playback
  point

5
Real-Time Applications

• Playback Buffer

T
6
Quality of Service Approaches

• Fine-grained
• Provide QoS to individual applications or flows
• Integrated Services Resource Reservation
  Protocol (RSVP)
• Variable bit rate services for ATM
• Coarse-grained
• Provide QoS to large classes of data or
  aggregated flows
• Differentiated Services (DIFFSERV)

7
Integrated Services - RSVP

• RSVP supports three service classes
• Guaranteed service
• Specified maximum delay
• Controlled load services
• Best effort

8
Integrated Services - RSVP

• Mechanisms
• Flow specification
• Tell the network the traffic characteristics and
  the QoS requirement
• Admission control
• Network decides if it can handle the flow
• Reservation
• Enable admission control
• Packet classification
• Map packets to flows
• Scheduling
• Determine which packets can go through first

9
RSVP Architecture
RSVP
RSVP Process
RSVP Process
Application
Policy Ctrl
Policy Ctrl
Routing Process
Admis. Ctrl
Packet Scheduler
Admis. Ctrl
Packet Scheduler
Classifier
Classifier
data
Router
Host
10
RSVP in Hosts and Routers

• Packet classifier determines the QoS class for
  each packet
• Admission control determines whether the node
  has sufficient available resources to supply the
  required QoS
• Policy control determines whether the user has
  administrative permission to make the
  reservation.
• Packet scheduler manages the various queues to
  guarantee the required QoS.

11
RSVP Session Definition

• RSVP session is defined by the triple
  (DestAddress, ProtocolID , DstPort)
• DestAddress refers to the IP destination address
  of the data packets be it a multicast or a
  unicast address.
• ProtocolID is the protocol ID
• The optional DstPort is a generalized destination
  port.

12
Fundamental RSVP Messages

• There are 2 fundamental messages in RSVP Resv
  messages and Path messages.
• Path messages are sent downstream along the
  uni-/multicast routes provided by the routing
  protocols.
• Path messages store a path state in each node
  along the way that includes the previous hops
  unicast address. This unicast address is used to
  route reservation messages hop-by-hop in the
  reverse direction.

Sender 1
R
R
PATH
Receiver C
R
R
Receiver A
R
Receiver B
13
Fundamental RSVP Messages

• Reservation messages are sent by receivers
  upstream towards the senders. These messages
  follow exactly the reverse paths along which the
  data packets will use.
• As reservation messages travel up they maintain a
  reservation state in each node along the path.

Sender 1
R
R
RESV (merged)
Receiver C
RESV (merged)
R
R
Receiver A
R
Receiver B
RESV
14
Path Message

• Session identifier.
• Timeout value.
• Previous hop address.
• Sender template.
• Contains sender IP and optionally sender port.
• Sender Tspec.
• This information is particularly used in the
  traffic control module.
• Adspec describes properties of the data path.
  Updated at each local traffic control.

15
Reservation Message

• A reservation request consists of a flow spec
  and a filter spec
• The flow spec specifies the desired QoS.
• The filter spec, along with the the session
  specification, defines the set of data packets to
  receive the QoS defined by the flow spec.
• A flow spec in a reservation request consists of
• A service class
• An Rspec parameter (R for reserve) which
  defines the desired QoS.
• A Tspec parameter (T for traffic) which
  defines describes the type of the data flow.

16
Flow Specification

• Rspec Describes service requested from network
• Controlled-delay level of delay required
• Guaranteed/predictive delay target
• Tspec Describe flows traffic characterization
• Average bandwidth burstiness token bucket
  filter
• Token rate r
• Bucket depth B
• Must have a token to send a byte
• Must have n tokens to send n bytes
• Accumulate tokens at rate of r per second
• Can accumulate no more than B tokens

17
Token Bucket Filters
Dropping Filter drops packets if token is not
available
Buffered Filter buffers data until tokens become
available
18
Token Bucket Filters

• Question
• Given a finite length data stream, will it be
  affected by a token bucket filter?

19
Token Bucket Filters
5

• Assume initially token bucket is empty
• At time30 seconds, queue length40
• At time50 seconds, queue length 480
• It takes (4805x20)/872.5 seconds for the queue
  to be emptied out.

20
Reservation Model

• At each intermediate node a reservation request
  triggers two general actions
• Make a reservation on the link This involves
  passing the request to both the admission control
  and policy control.
• If either test fails the reservation request is
  rejected and the RSVP process returns an error to
  the receiver which initiated the request.
• If both succeed then the node sets its packet
  classifier to select the data packets defined by
  the filter spec. It also talks to the scheduler
  to set the desired QoS defined by the flow spec
  parameter.
• Send the reservation request upstream. The
  request that is sent does not necessarily have
  the same flow spec as the request received from
  downstream.

21
Reservation Styles

• Wildcard-Filter (WF) Style -- WF(Q)
• 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.

a
c
R1
S1
Router
R2
d
S2
R3
b
Router Configuration
a
c
WF(4B) lt--
lt-- WF(4B)
S1
Reserves4B
lt--WF(3B)
Reserves3B
d
S2
b
WF(4B) lt--
lt--WF(2B)
22
Reservation Styles

• Fixed-Filter (FF) Style -- FF(SQ), FF(S1(Q1),
  S2(Q2), )
• Creates distinct reservations for data packets
  from a particular sender, not sharing them with
  other sender packets for the same session.

a
c
R1
S1
Router
R2
d
S2
R3
b
Router Configuration
lt-- FF(S14B,S25B)
a
c
FF(S14B) lt--
Reserves S14B, S25B
S1
lt--FF(S13B,S3B)
b
Reserves S13B, S3B
S2
d
lt--WF(S1B)
FF(S25B,S3B) lt--
23
Reservation Styles

• Shared-Explicit (SE) Style -- SS((S1, S2, ) Q)
• Creates a single reservation shared by selected
  upstream senders.
• Allows a receiver to explicitly specify the set
  of senders to be included.

a
c
R1
S1
Router
R2
d
S2
R3
b
Router Configuration
a
c
SE(S13B) lt--
lt-- SE((S1,S2)B)
S1
Reserves S1,S2B
b
lt--SE((S1,S3)3B)
Reserves S1,S2,S33B
d
S2
lt--SE(S22B)
SE(S2,S33B) lt--
24
RSVP Reservation Styles
Reservations
Sender Selection
Shared
Distinct
Shared Explicit
Explicit
Fixed Filter
Wildcard Filter
None
Wildcard

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

25
Merging Flow Specifications

• The following steps are used to calculate the
  effective flowspec (Re, Te) to be installed on an
  interface
• An effective flowspec is determined for the
  outgoing interface. This means computing the
  Least Upper Bound of the flow specs. Least Upper
  Bound (LUB) here refers to an adequate operation
  which calculates a flow spec that is at least as
  large as each of next-hop flow specs. The result
  of this calculation is a pair (Re, Resv_Te) where
  Re is the effective Rspec, and Resv_Te is the
  effective Tspec of the Resv message.

26
Confirmation Message

• To request a confirmation for its reservation
  request a receiver Rj includes in the Resv
  message a confirmation request containing Rjs IP
  address.
• If the reservation request from Rj is equal to or
  smaller than the reservation in place on a node,
  its Resv is not forwarded upstream any further,
  and if the request included a request
  confirmation object, a ResvConf message is sent
  back to Rj.
• The confirmation mechanism has the following
  consequences
• A new reservation request with a flow spec larger
  than any in place for a session will result in
  either a ResvErr, or a ResvConf message. A
  resulting ResvConf will be an end to end
  confirmation (i.e. issued by the sender to the
  receiver).
• The receipt of a ResvConf gives no guarantees.

27
RSVP Soft States

• State maintained by RSVP is dynamic
• To change the desired QoS a sender simply sends
  revised Path messages.
• This will cause appropriate update in all nodes
  along the path. Unused states (due to a route
  change for example) will time out if they are not
  explicitly torn down.
• State is refreshed hop-by-hop to allow merging.
• When the received state differs from the stored
  state the stored state is updated.
• If this update causes results in a modification
  of the state to be forwarded in refresh messages,
  then these refresh messages are generated and
  forwarded immediately.
• Otherwise propagation of a change stops when it
  reaches a point where merging causes no resulting
  state change.

28
Problems with RSVP

• It requires each router to establish per-flow
  state.
• A core router could handle millions of
  connections.
• RSVP does not scale!

29
Differentiated Services

• Goal
• Scalability through the use of only a small
  number of service classes
• Two classes
• Expedited forwarding and assured forwarding
• Diffserv
• Proposes 6 bits of IP ToS field (26 64 classes)
• Questions
• Who is allowed to set the premium bit?
• Typically an ISP
• How do routers react to such a classification?
• IETF has specified per-hop behavior

30
Differentiated Services

• Expedited forwarding
• Essentially establish a virtual circuit with
  reserved resources
• Need to strictly limit the amount of traffic
  receiving expedited forwarding
• Give strict priority
• Use weighted fair queueing (WFQ) and assign
  sufficiently large weights for traffic receiving
  expedited forwarding

31
Differentiated Services

• Profile meters at the edges of ISP networks could
  mark packets as in or out
• If a flow has sent more packets than its
  specification, all the surplus packets are marked
  as out.
• Core routers differentially drop packets
• Use RED but with in and out packets (RIO)

32
Digress Random Early Detection

• Hosts
• Implement TCP congestion control
• Back off when a packet is dropped
• Routers
• Compute average queue length (exponential moving
  average)
• AvgLen (1 Weight) AvgLen Weight
  SampleLen
• 0 lt Weight lt 1 (usually 0.002)
• SampleLen is queue length at packet arrival time

33
RED Dropping Policy

• If AvgLen ? MinThreshold
• Enqueue packet
• If MinThreshold lt AvgLen lt MaxThreshold
• Calculate P and drop arriving packet with
  probability P
• If MaxThreshold ? AvgLen
• Drop arriving packet

34
RED Dropping Probability

• Computing P
• P is a function of AvgLen and Count
• Count is the number of packets that have arrived
  since last reset
• Reset happens when either a packet is dropped or
  AvgLen is above MaxThreshold

35
Assured Forwarding -- RIO

• Use two instances of RED, one for in packets
  and the other for out packets.
• The thresholds are set so that the router will
  drop out packets more aggressively if need be.
• AveLen for in packets refers to the average
  queue length for in packets, while that for
  out packets refers to the average total queue
  length.

36
QoS in ATM

• Similar to RSVP
• Five service classes
• Constant bit rate (CBR)
• Variable bit rate (VBR) real-time
• Variable bit rate (VBR) non-real-time
• Unspecified bit rate (UBR)
• Available bit rate (ABR)

37
Comparison of RSVP and ATM

• RSVP
• Receiver generates reservation
• Soft state (refresh/timeout)
• Separate from route establishment
• QoS can change dynamically
• Supports receiver heterogeneity
• ATM
• Sender generates connection request
• Hard state (explicit delete)
• Concurrent with route establishment
• QoS is static for life of connection (except ABR)
• Uniform QoS to all receivers