Download Presentation

IntServ, DiffServ, and TCP - What
Does It All Mean?
Glynn Rogers
Research Leader - Advanced Networks
Technology
CSIRO Telecommunications and Industrial Physics
[email protected]
Quality of Service (QoS)
 A major driving force in Internet evolution
 Not simply defined - means many things to
many people
 Has sense of predictable network behaviour
 Central idea is provision of network
resources that an application requires to
perform adequately
QoS is Generating a Confusing
Array of Acronyms
QoS
CoS
Intserv
Diffserv
RSVP
MPLS
But Its All Beginning to Fit
Together
 Primary aim is to convey my emerging picture of
how
 Secondary aim is to argue that something new and
important is happening here
– a whole new area of networking is developing
– merging of traditional ‘routing and addressing’ IP world
with telecommunications engineering
– the technical consequence of ‘convergence’
– complex - won’t happen overnight
Firstly, a Caveat or Two
 What follows is based squarely on the documentation
of the relevant industry ‘standards’ organisations:
– the ATM Forum
– the Internet Engineering Task Force (IETF)
 These are my interpretations - any confusions are mine.
 Its the ‘big picture’ that counts - don’t worry about the
detail.
– not a tutorial - convey general impression by example -no
attempt at completeness
Why Do We Need Such a
Revolutionary Change?
 Current ‘best effort’ technology is essentially a
quarter of a century old
 Two factors driving the development of a new
generation of multimedia applications
– commercialisation of the Internet
– Increasing availability and decreasing cost of bandwidth
 No evidence of ‘free bandwidth’ scenario emerging
– rejected in RFC1633 (1994) - still true
– demand always rises to meet supply
QoS is Not New
 Telephone network has QoS
– economics and technology based on a single application
– highly developed engineering
– but one size fits all
 BISDN an attempt by telephony world to generalise
network to encompass diverse applications
 ATM technology - first full exploration of QoS on
demand concepts
A Quick Look at ATM
 ATM is connection oriented
– end to end virtual connection established with negotiated
QoS characteristics
» Service category - CBR, VBR etc
» traffic characteristics - peak rate, sustained rate, burst size etc
» QoS parameters - loss rate, delay, delay jitter
 SVC establishment requires both
– ‘QoS routing’ (PNNI) and
– resource allocation in traversed switches (signaling)
Quality of Service and Resource
Management
 Fundamental resource is output link rate
 Access managed via scheduling discipline
 Bursty input traffic held in buffers
– adds delay and jitter
– overflow causes packet loss
 These factors determine QoS at network level
 Optimise via buffer management and scheduler
parameter setting
QoS in the Internet
 Internet Engineering Task Force (IETF) is evolving
QoS support mechanisms for the Internet - two
approaches
– The Integrated Services Internet
» QoS for individual microflows
» perhaps too complex for large networks - won’t scale easily
– Differentiated Services - more scaleable
» lose sight of individual microflows - Behaviour Aggregates
Why not Just Stick with ATM?
 Original ATM concept was QoS overkill
– end-to-end defined channel
– assumed long lived flows with specific requirements
– connection setup overheads relatively small
 OK for telephony, high quality VoD etc
 But Internet traffic is dominated by TCP
– significant proportion of short lived flows (eg Web
downloads of text and image pages
– even streaming video applications are using TCP
IETF IntServ Introduces Another
Traffic Class
 Newer ‘real time’ applications (Web based in
particular) are elastic or adaptable to modest
fluctuations in network performance
 An example is streaming video over TCP
– TCP provides rate adaptation to network load
– application can respond to blocking at socket calls
» change frame rate (but careful with audio)
» hierarchical coding provides graceful degradation
» MPEG 4 supplies a formal framework
IntServ Controlled Load Service
 Based on observation that for this class of traffic
the existing Internet works fine if it is not heavily
loaded
 Use resource allocation to provide performance
equivalent to a lightly loaded network
 Can base definition on qualitative specifications as
distinct from quantitative specifications of ATM
IntServ Also Provides for
Established Traffic Classes
 A growing number of ‘demanding’ applications
– VoIP has stringent requirements on packet loss and delay
– Guaranteed Service designed for such applications
 Traditional ‘best effort’ service class is still required
for non real time applications
 IntServ provides a framework for defining new
service types
The Integrated Services Concept
 Internal network resources are committed to
individual end-to-end microflows to provide the
QoS the service requires - connection setup
 Applications must specify the traffic characteristics
of the microflow
– token bucket model - rate and burst size specs.
– flows are policed to ensure conformance
 Network performs Connection Admission Control
 Method of resource allocation up to implementor
Why Not Just Extend ATM?
 ATM is based on Layer 2 switching
 IntServ retains Layer 3 forwarding mechanism
– essentially a connectionless environment
– flows are more abstract than a VC - akin to ‘traffic
trunk’ concept in MPLS
 IntServ’s signalling protocol - RSVP - is receiver
driven and ‘soft state’ based
– much greater compatibility with multicast
So What Went Wrong?
 ‘RSVP is dead’ reports are exaggerated
– QoS is complex
– requires systems rather than individual protocol approach
– more time required for development and acceptance
 Nevertheless there is a problem
– IntServ inconsistent with Internet philosophy of keeping
complexity to the network edge
– requires interior nodes to retain state for each microflow
– ‘state explosion’ problem in interior of big networks
Enter Differentiated Services
 DiffServ distinguishes between end-to-end services
and the behavior of the individual network
components required to support them
 DiffServ is based on a set of defined Per Hop
Behaviours (PHB’s) specified via an IP header byte,
the DS byte
 3 types of PHB so far defined in RFC’s
– ‘Class Selectors’ - priority based - cf IP priority
– Expedited Forwarding (EF)
– Assured Forwarding (AF)
Diffserv Emphasis is on
Individual Interfaces
 ‘State explosion’ problem is avoided by
aggregating traffic requiring the same QoS at each
interface
 Each Behaviour Aggregate experiences the node
performance specified in the required Per Hop
Behaviour
 The behaviour aggregate and PHB are determined
by the DiffServ Code Point (DSCP) carried in the
DS Byte
Expedited Forwarding and
Assured Forwarding PHB’s
 ‘… about bandwidth allocation’ - via schedulers
such as weighted fair queuing as well as buffer
management
 Expedited Forwarding - reserved resources
(aggregated) - signalling (RSVP?) - VoIP
 Assured Forwarding - 4 classes
– intended for controllable sources such as TCP
– controlled packet drops - 3 levels of drop precedence
with a separate DSCP for each level
Example of an Assured
Forwarding Mechanism
AF class 1
AF class 2
Weighted
Fair
Queuing
Scheduler
drop
probability
AF class 3
AF class 4
buffer with 3 level
RED mechanism
Seeing the Woods for the Trees
- Diffserv Domains
 Domain - collection of nodes under one administration
with common policies for routing, QoS, etc
 Domains interact via Service Level Agreements
– traffic policy written as Service Level Specifications
– traffic managed using Traffic Conditioning Specifications
 Domains interconnnect via boundary nodes which
contain Traffic Conditioning Elements
– packet filters, meters, shapers, policers etc
– note these all act on aggregates specified by the DSCP
Management Issues Provisioning Diffserv Domains
 Both EF and AF PHB’s require explicit resource
allocation - bandwidth, buffer space etc
 Mechanisms for allocating resources over domain a
research issue
– static allocation - management systems
– dynamic allocation - bandwidth broker - active networks
 Routing implications - traffic engineering
– constrained routing
– MPLS
Of Microflows and Macroflows IntServ over DiffServ
 Policing at domain boundaries on aggregates
 Without individual CAC all flows in an aggregate
can suffer from over commitment
 IETF Integrated Services over Specific Lower
Layers (ISSLL) working group proposes using
DiffServ network as akin to, say, ATM link
– Aggregation of RSVP requests into single RSVP action
– mapping of IntServ services onto Diffserv Per Domain
Behaviours - determined by node PHB’s
Example Scenario - TCP based
Streaming Video
 Assume a properly resourced Diffserv domain
 Assume a Bandwidth Broker which can interact with
RSVP to provide IntServ admission control
 Combine Controlled Load with Assured Forwarding
– both in spirit of elastic flows on lightly loaded network
 Require policing to control average TCP flow rate
– nonconforming packets ‘marked down’ to a DSCP giving
higher drop probability in AF class
– we have experimentally demonstrated that this works!
Traffic
Generator #1
Traffic
Generator #2
Traffic Sink
CISCO 7505
Router
Linux
Router
Traffic
Generator #3
IntServ Domain
DiffServ Domain
IntServ Domain
TCP Rate Control Using Source
Policing and Assured Forwarding
Video On
Demand Server
Video On
Demand Client
Accelar Switch
Router
Linux
Router
Traffic Generator
IntServ Domain
DiffServ Domain
IntServ Domain