Int Serv Diff Serv and TCP What Does

  • Slides: 28
Download presentation
Int. Serv, Diff. Serv, and TCP - What Does It All Mean? Glynn Rogers

Int. Serv, Diff. Serv, and TCP - What Does It All Mean? Glynn Rogers Research Leader - Advanced Networks Technology CSIRO Telecommunications and Industrial Physics glynn. rogers@tip. csiro. au

Quality of Service (Qo. S) · A major driving force in Internet evolution ·

Quality of Service (Qo. S) · 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

Qo. S is Generating a Confusing Array of Acronyms Qo. S Co. S Intserv

Qo. S is Generating a Confusing Array of Acronyms Qo. S Co. S Intserv Diffserv RSVP MPLS

But Its All Beginning to Fit Together · Primary aim is to convey my

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

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

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 RFC 1633 (1994) - still true – demand always rises to meet supply

Qo. S is Not New · Telephone network has Qo. S – economics and

Qo. S is Not New · Telephone network has Qo. S – 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 Qo. S on demand concepts

A Quick Look at ATM · ATM is connection oriented – end to end

A Quick Look at ATM · ATM is connection oriented – end to end virtual connection established with negotiated Qo. S characteristics » Service category - CBR, VBR etc » traffic characteristics - peak rate, sustained rate, burst size etc » Qo. S parameters - loss rate, delay jitter · SVC establishment requires both – ‘Qo. S routing’ (PNNI) and – resource allocation in traversed switches (signaling)

Quality of Service and Resource Management · Fundamental resource is output link rate ·

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 Qo. S at network level · Optimise via buffer management and scheduler parameter setting

Qo. S in the Internet · Internet Engineering Task Force (IETF) is evolving Qo.

Qo. S in the Internet · Internet Engineering Task Force (IETF) is evolving Qo. S support mechanisms for the Internet - two approaches – The Integrated Services Internet » Qo. S 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 Qo. S overkill

Why not Just Stick with ATM? · Original ATM concept was Qo. S overkill – end-to-end defined channel – assumed long lived flows with specific requirements – connection setup overheads relatively small · OK for telephony, high quality Vo. D 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 Int. Serv Introduces Another Traffic Class · Newer ‘real time’ applications (Web based

IETF Int. Serv 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

Int. Serv Controlled Load Service · Based on observation that for this class of

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

Int. Serv Also Provides for Established Traffic Classes · A growing number of ‘demanding’

Int. Serv Also Provides for Established Traffic Classes · A growing number of ‘demanding’ applications – Vo. IP 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 · Int. Serv provides a framework for defining new service types

The Integrated Services Concept · Internal network resources are committed to individual end-to-end microflows

The Integrated Services Concept · Internal network resources are committed to individual end-to-end microflows to provide the Qo. S 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 ·

Why Not Just Extend ATM? · ATM is based on Layer 2 switching · Int. Serv retains Layer 3 forwarding mechanism – essentially a connectionless environment – flows are more abstract than a VC - akin to ‘traffic trunk’ concept in MPLS · Int. Serv’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 – Qo. S

So What Went Wrong? · ‘RSVP is dead’ reports are exaggerated – Qo. S is complex – requires systems rather than individual protocol approach – more time required for development and acceptance · Nevertheless there is a problem – Int. Serv 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 · Diff. Serv distinguishes between end-to-end services and the behavior of

Enter Differentiated Services · Diff. Serv distinguishes between end-to-end services and the behavior of the individual network components required to support them · Diff. Serv 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

Diffserv Emphasis is on Individual Interfaces · ‘State explosion’ problem is avoided by aggregating traffic requiring the same Qo. S 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 Diff. Serv Code Point (DSCP) carried in the DS Byte

Expedited Forwarding and Assured Forwarding PHB’s · ‘… about bandwidth allocation’ - via schedulers

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? ) - Vo. IP · 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

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

Seeing the Woods for the Trees - Diffserv Domains · Domain - collection of nodes under one administration with common policies for routing, Qo. S, 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

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 Int. Serv over Diff. Serv · Policing at domain boundaries

Of Microflows and Macroflows Int. Serv over Diff. Serv · 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 Diff. Serv network as akin to, say, ATM link – Aggregation of RSVP requests into single RSVP action – mapping of Int. Serv services onto Diffserv Per Domain Behaviours - determined by node PHB’s

Example Scenario - TCP based Streaming Video · Assume a properly resourced Diffserv domain

Example Scenario - TCP based Streaming Video · Assume a properly resourced Diffserv domain · Assume a Bandwidth Broker which can interact with RSVP to provide Int. Serv 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

Traffic Generator #1 Traffic Generator #2 Traffic Sink CISCO 7505 Router Linux Router Traffic Generator #3 Int. Serv Domain Diff. Serv Domain Int. Serv Domain

TCP Rate Control Using Source Policing and Assured Forwarding

TCP Rate Control Using Source Policing and Assured Forwarding

Video On Demand Server Video On Demand Client Accelar Switch Router Linux Router Traffic

Video On Demand Server Video On Demand Client Accelar Switch Router Linux Router Traffic Generator Int. Serv Domain Diff. Serv Domain Int. Serv Domain