4th Edition: Chapter 1

1
CSCD 433/547Advanced Networks
Lecture 15 Quality of Service

1
2
Topics

• Quality of Service (QOS)
• Real-time applications
• Integrated Service
• Differentiated Service

2
3
Introduction

• Distinguishing characteristic is
• Timely arrival is critical
• We need assurance from network that data will
  arrive on time!
• Need new ways to ask network for guarantees
• Different model than best effort
• Some packets will need to be treated differently
  than others
• Quality of service or QOS is name for this

4
Introduction

• Increasingly, multimedia dominates network
  traffic
• Characteristic of multimedia
• Real-time nature of data
• Not enough that data arrives, but now must
  arrive on time
• For this to work
• Not every application needs real-time service
• But, network must treat those that do differently
• Think of first class line at Airline ticket
  counter
• Some people get to go first, others must wait

4
5
QOS Two classes

• Classify applications into two classes
• Real-time
• Non-realtime
• Real-time
• VOIP, Real-time music, Video
• Non-realtime
• Web browsing, email, FTP, SSH
• Where do multi-player games fit?

5
6
Real-time Example

• Real-time example, audio application
• Samples from microphone, digitizes them using
  Analog to digital converter
• Digital samples placed in packets
• -gt sent to receiving host
• Receiving host, data must be played back at
  certain rate

6
7
Real-time Example continued

• If voice samples collected at rate of 1/125
  microseconds
• Should be played back at same rate
• Each sample has playback time of 125 microseconds
  later than previous sample
• If data arrives after its playback time, it is
  useless
• One distinguishing feature of real-time
• In non-realtime applications, late data is still
  useful

7
8
Insuring Constant Playback

• Since we are working in best effort environment,
  how do we insure constant playback?
• Buffer, buffer, buffer
• Make sure at receiver we buffer enough data to
  have in reserve to always be able to provide a
  store of packets to application

8
9
Buffering in Action

• Playback buffer in action

Packets buffered
Packets generated
Packets played
Packets Arrive

9
10
Buffering in Action

• Delay might still be too variable to be useful
• If too many packets delayed, buffering wont
  help, if few packets delayed, buffering works

One day of one-way traffic across a single path
across Internet
What does this graph tell us?

10
11
Principles for QOS Guarantees

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

12
Principles for QOS Guarantees

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

13
Principles for QOS Guarantees

• 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

14
Principles for QOS Guarantees

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

15
Principles for QOS Guarantees

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

16
QOS Approaches

• Range of services developed to meet range of
  application needs
• Two classes
• Fine-grained provide QOS to individual
  applications or flows
• Course-grained provide QOS to large classes of
  data or aggregated traffic
• Fine-grained
• Integrated Services QOS architecture developed
  by IETF used with RSVP
• Course-grained
• Differentiated Services

16
17
Integrated Services

• Body of work produced by IETF
• Around 1995-1997
• Integrated services working group developed
  specifications of Service Classes
• Designed to meet needs of some applications
• Defined how RSVP used to make reservations using
  those service classes
• First, describe service classes and later how
  RSVP works

17
18
Classification of Applications
Applications can be classified based on their
requirements and responses for delay

18
19
Service Classes

• Service class 1, Guaranteed Service
• Designed for Intolerant Applications
• Applications require that packet never arrives
  late
• Network needs to guarantee that max delay for a
  packet has a value
• Application can then set playback point so no
  packet ever arrives after its playback time

19
20
Service Classes

• Service Class 2 - Controlled Load
• Meets needs for Tolerant, adaptable applications
• Some applications such at vat, produce reasonable
  quality for loss rates 10 or less
• Goal of controlled load
• Emulate lightly loaded network even thought
  network may be under heavy load
• How do we do this?

20
21
Service Classes

• Implement a queuing mechanism
• Like Weighted Fair Queuing (WFQ)
• Isolate controlled load traffic from other
  traffic
• Use Admission Control to limit amount of
  controlled load traffic on a link so load is kept
  low
• More on Admission Control later
• Idea is dont want to overload a given link so
  that it cant achieve QOS requests from
  Controlled Load Traffic

21
22
QOS Mechanisms

• QOS mechanisms are still under development by
  Internet design community
• Best effort service tell network where we want
  packets to go and leave it at that
• Real-time service involves telling network more
  about the service we want
• Can ask . What kind of data do we need to
  provide for network to satisfy our needs?

22
23
Data for QOS

• Delay
• Say, need max delay of 100 ms
• Type of data
• Low bandwidth needs fewer resources
• High bandwidth needs more
• Called a Flowspec
• Includes the above type of data

23
24
Flow Spec

• Whats in a Flow Spec
• Tspec traffic characteristics
• Rspec Service requested from network
• Rspec Controlled load or guaranteed service
• Tspec
• More complicated to describe traffic requirements
• Have 10 flows, arrive at a switch on separate
  ports
• Over a 10 Mbps link
• On average, flows generate 1 Mbps
• No problem on average
• But, for variable rate flows, will send more
  traffic than that
• If enough flows exceed 1 Mbps, total rate gt 10
  Mbps

24
25
Flow Control

• Must be some way to characterize how bandwidth
  for source varies/time
• Token Bucket Filter
• Uses two parameters, a token rate, r and
• Bucket depth, B
• To send a byte
• Must have a token, n send packet of length n,
  need n tokens
• Start with 0 tokens, accumulate them at r/sec
• Can accumulate max of B tokens, and can send a
  burst of B tokens into the network but cant send
  faster than r bytes/sec

25
26
Flow Control

• Example Token Bucket Filter
• Two flows A and B
• A generates data, steady flow of 1 MBps, average
  is 1 MBps also
• Described by token bucket filter with r 1 MBps
  and B 1 byte
• A sends bytes right away, since its sending
  steadily
• B average is also 1 MBps but sends data at .5
  Mbps for 2 secs and 2 MBps for 1 sec
• B needs bucket depth of at least 1 MB
• So, B saves up to 2X .5 1 MB of tokens which it
  spends in 3rd second, along with new tokens it
  accrues in that seconds to send data at 2 MBps

26
27
Token Bucket Filter

• Two Flows, A and B
• Same Average flow, 1 MBps, different traffic
  characteristics

27
28
Admission Control

• New flow desires level of service
• Admission control looks at Tspec and Rspec
• Tries to decide if service can be provided given
  current resources
• Cant cause previous flows to get worse service
• If it can provide service, flow is admitted
• If it cant provide service, flow is denied
• Difficult part, when do you say yes or no?

28
29
Admission Control

• Sensitive to type of requested service
• Sensitive to queuing discipline in routers
• Guaranteed Service
• Decision straightforward if Weighted Fair Queuing
  used
• Controlled Load
• Decision can be based on heuristics
• Last time a flow with this Tspec was admitted,
  class exceeded acceptable bandwidth, so say no or
• Current delays are not much, can admit another
  flow

29
30
Admission Control

• Different from policing
• Policing is on a per-packet basis while
• Admission control is a per flow decision
• If flow not behaving
• Going outside its Tspec
• Will interfere with other flows, some action is
  required
• Actions
• Can include dropping the flow
• Check for interference, and if not, mark it as
  non-conforming, but send it on
• These marked packets will be dropped should
  bandwidth become an issue

30
31
Admission Control

• Closely related to network policy
• CEOs packets always get priority
• But, still might fail if resources are not
  available
• Policy a much investigated topic at present time

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

33
Diff Serv

• Who sets the bit on the packets?
• Under what circumstances would you set the bit?
• What does the router do with that information?

34
DiffServ

• ISP could set the bit for a particular companys
  traffic
• Router can treat packets differently on a per hop
  basis
• So, in packet header, TOS field used 6 bits and
  allocated it for Diffserv codes
• Two types of forwarding behaviors
• EF Expedited Forwarding
• AF Assured Forwarding

35
DiffServ EF, AF

• Expedited Forwarding
• Forwarded minimum delay and loss
• But, routers then can only allow so much EF
  traffic into domain
• Edge routers can be configured to do this
• Assured Forwarding
• RED with IN and OUT
• So, what is RED?

36
RED - Random Early Detection

• Each router monitors own queue
• When it decides congestion about to happen,
  notifies source to adjust its congestion window
• RED invented by Sally Floyd and Van Jacobson in
  1990s
• Doesnt explicitly notify source
• RED implicitly notifies source
• Drops one of the packets
• Notified by duplicate Ack or timeout

36
37
Diffserv AF

• RED with IN and Out
• In and Out refers to way packets are marked
• Routers allowed to mark packets
• Profile for customer X
• Customer X allowed to send packets up to y Mpbs
  of assured traffic
• Edge router marks packets as being in or out of
  the profile
• If sends lt y Mbps, all packets marked in but
  once rate gt y Mbps, packets marked out

38
Diffserv - AF

• Profile meter at edge of network and Red with In
  and Out (RIO) on all routers in ISP network
• Provides high assurance that IN packets will get
  service needed
• But, not a guarantee of delivery
• If in packets dont congest the link, rare that
  in packets dropped, other traffic dropped first
• RIO can be generalized to provide more classes of
  traffic

39
References

• Diffserv
• http//www.cisco.com/en/US/technologies/tk543/tk76
  6/technologies_white_paper09186a00800a3e2f_ps6610_
  Products_White_Paper.html

39
40
Next Lecture Read VOIP only in
Chapter 9 End

40