ip qos issues

Status: Lecture

File name: IP_QoS_01

Originator: A. Kassler

IP QoS issuesIP QoS issues

From IntServ to DiffServ to Adaptive QoS Mangement

Status: Lecture



AgendaAgenda

• QoS and IP networks• IntServ• DiffServ• Adaptive QoS Management

Status: Lecture



QoS enabling a NetworkQoS enabling a Network

• Goals– Improve network service perceived by applications– Give the network administrator control over network

resource usage– These are really the same

• If there were infinite network resources, QoS would not be necessary– but - there are congestion points– QoS is about deciding what traffic gets access to

resources at these points

Status: Lecture



How can this be achieved?How can this be achieved?

• Correlate packets with traffic sources– sending user, receiving user, application– classify according to common fields in packet headers

• Give certain traffic preferential access to resources at congestion points– reserve adequate capacity on transmit interfaces– bypass queues on transmit interfaces– extra buffer space in network elements

Status: Lecture



Specifying traffic: Tspec Specifying traffic: Tspec

IDEA: call must describe traffic that it will inject into net

leaky bucket proposal: traffic entering net filtered by leaky bucket regulator:

• B: maximum burst size • r: average rate • amount traffic entering over any interval of length t, less than b + rt

Status: Lecture



Token BucketToken Bucket

Possible token bucket uses: – shaping, policing, marking

• delay pkts from entering net (shaping) • drop pkts that arrive without tokens (policing

function) • let all pkts pass through, mark pkts: those

with tokens, those without • network drops pkts without tokens in time of

congestion (marking)

Status: Lecture



Traffic classesTraffic classes

• Networks should match offered service to source requirements (corresponds to utility functions)

• Example: telnet requires low bandwidth and low delay – utility increases with decrease in delay– network should provide a low-delay service– or, telnet belongs to the low-delay traffic class

• Traffic classes encompass both user requirements and network service offerings

Status: Lecture



Traffic classes - detailsTraffic classes - details

• A basic division: guaranteed service and best effort– like flying with reservation or standby

• Guaranteed-service– utility is zero unless app gets a minimum level of

service quality• bandwidth, delay, loss

– open-loop flow control with admission control– e.g. telephony, remote sensing, interactive multiplayer

games

• Best-effort– send and pray– closed-loop flow control– e.g. email, net news

Status: Lecture



GS vs. BE (cont.)GS vs. BE (cont.)

• Degree of synchrony– time scale at which peer endpoints interact– GS are typically synchronous or interactive

• interact on the timescale of a round trip time• e.g. telephone conversation or telnet

– BE are typically asynchronous or non-interactive• interact on longer time scales• e.g. Email

• Sensitivity to time and delay– GS apps are real-time

• performance depends on wall clock

– BE apps are typically indifferent to real time• automatically scale back during overload

Status: Lecture



Traffic subclasses (roadmap)Traffic subclasses (roadmap)

• ATM Forum – based on

sensitivity to bandwidth

– GS • CBR, VBR

– BE• ABR, UBR

• IETF– based on

sensitivity to delay– GS

• intolerant • tolerant

– BE• interactive burst • interactive bulk• asynchronous bulk

Status: Lecture



ATM Forum GS subclassesATM Forum GS subclasses

• Constant Bit Rate (CBR)– constant, cell-smooth traffic– mean and peak rate are the same– e.g. telephone call evenly sampled and

uncompressed– constant bandwidth, variable quality

• Variable Bit Rate (VBR)– long term average with occasional bursts– try to minimize delay– can tolerate loss and higher delays than CBR– e.g. compressed video or audio with constant

quality, variable bandwidth

Status: Lecture



ATM Forum BE subclassesATM Forum BE subclasses

• Available Bit Rate (ABR)– users get whatever is available– zero loss if network signals (in RM cells) are

obeyed– no guarantee on delay or bandwidth

• Unspecified Bit Rate (UBR)– like ABR, but no feedback– no guarantee on loss– presumably cheaper

Status: Lecture



IETF GS subclassesIETF GS subclasses

• Tolerant GS– nominal mean delay, but can tolerate “occasional” variation– not specified what this means exactly– uses controlled-load service

• controlled load: "a QoS closely approximating the QoS that same flow would receive from an unloaded network element, but uses admission control to assure that this service is received even when the network element is overloaded." even at “high loads”, admission control assures a source that its service “does not suffer”

– it really is this imprecise!

• Intolerant GS– need a worst case delay bound– equivalent to CBR+VBR in ATM Forum model

Status: Lecture



IETF BE subclassesIETF BE subclasses

• Interactive burst– bounded asynchronous service, where bound is

qualitative, but pretty tight• e.g. paging, messaging, email

• Interactive bulk– bulk, but a human is waiting for the result– e.g. FTP

• Asynchronous bulk– junk traffic– e.g netnews

Status: Lecture



Some points to ponderSome points to ponder

• The only thing out there is CBR and asynchronous bulk!

• These are application requirements. There are also organizational requirements (link sharing)

• Users needs QoS for other things too!– billing– privacy– reliability and availability

Status: Lecture



Time scalesTime scales

• Some actions are taken once per call– tell network about traffic characterization and request

resources– in ATM networks, finding a path from source to destination

• Other actions are taken during the call, every few round trip times– feedback flow control

• Still others are taken very rapidly,during the data transfer– scheduling– policing and regulation

• Traffic management mechanisms must deal with a range of traffic classes at a range of time scales

Status: Lecture



Summary of mechanisms at each Summary of mechanisms at each time scaletime scale

• Less than one round-trip-time (cell-level)– Scheduling and buffer management– Regulation and policing– Policy routing (datagram networks)

• One or more round-trip-times (burst-level)– Feedback flow control– Retransmission– Renegotiation

Status: Lecture



Summary (cont.)Summary (cont.)

• Session (call-level)– Signaling– Admission control– Service pricing– Routing (connection-oriented networks)

• Day– Peak load pricing

• Weeks or months– Capacity planning

Status: Lecture



RenegotiationRenegotiation

• An option for guaranteed-service traffic• Static descriptors don’t make sense for many

real traffic sources– interactive video

• Multiple-time-scale traffic– burst size B that lasts for time T– for zero loss, descriptors (P,0), (A, B)

• P = peak rate, A = average

– T large => serving even slightly below P leads to large buffering requirements

– one-shot descriptor is inadequate

Status: Lecture



Renegotiation (cont.)Renegotiation (cont.)

• Renegotiation matches service rate to traffic• Renegotiating service rate about once every

ten seconds is sufficient to reduce bandwidth requirement nearly to average rate– works well in conjunction with optimal

smoothing

• Fast buffer reservation is similar– each burst of data preceded by a reservation

• Renegotiation is not free– signaling overhead– call admission ?

• perhaps measurement-based admission control

Status: Lecture



SignalingSignaling

• How a source tells the network its utility function

• Two parts– how to carry the message (transport)– how to interpret it (semantics)

• Useful to separate these mechanisms• call setup protocol needed

– to perform call admission– to reserve resources at each router on end-end

path

Status: Lecture



Signaling semanticsSignaling semantics

• Classic scheme: sender initiated• SETUP, SETUP_ACK, SETUP_RESPONSE• Admission control• Tentative resource reservation and

confirmation• Simplex and duplex setup• Doesn’t work for multicast

Status: Lecture



Resource translationResource translation

• Application asks for end-to-end quality• How to translate to per-hop requirements?

– E.g. end-to-delay bound of 100 ms– What should be bound at each hop?

• Two-pass– forward: maximize (denial!)– reverse: relax– open problem!

Status: Lecture



Resource ControlResource Control

• Tasks– Admission Control Tests

at connection setup• enough capacity for new

connection• all existing connections

should keep their QoS– Reservation of resources

at connection setup– Scheduling of resources

during runtime• similar to processor

scheduling– Release of resources

Ban

dbre

ite

Zeit

Rest

Verb 2

Verb 1

maximale Netzkapazität

Status: Lecture



Link Layer: critical QoS Link Layer: critical QoS componentcomponent

Buffering and bandwidth: the scare resources • cause of loss and delay • Scheduler as example for resource controller

– packet scheduling discipline, buffer management will determine loss, delay seen by a call

– Scheduling disciplines:• FCFS • Fair Queuing (FQ) • Weighted Fair Queueing (WFQ)

Outgoing link

router

Link level packet schedulingincoming links

Status: Lecture



Scheduling: FCFSScheduling: FCFS

• FCFS (First Come First Served) oder FIFO– packets are processed according to their arrival time– buffer overflow-> packets are lost

• congestion control at the endpoints of the network necessary– in todays internet IP routers. TCP deals with congestion

control– Advantage: simple to implement– Disadvantage: No QoS guarantees, because it does not

distinguish between packet priorities• FCFS and Priorities

– several queues with different priorities– within each queue: FCFS– highest priority queue served first– no guarantees within each priority class

Status: Lecture



Scheduling: Fair QueueingScheduling: Fair Queueing

• Idea: Fairness. Each flow gets same amount of bandwidth

• Advantages: – misbehaving source does

not influence other flows

• Problems:– many queues– Insufficient algorithm: service

rate depends on packet size

• Guarantees minimal throughput

Outgoing link

Flow 1 pkts

Flow N pkts

Per Flowpacket Queues

Round-robin service: • assume fixed length pkts, N sessions • session i gets to send 1 pkt each "turn" • if session i has no pkt, i+1 gets chance

Status: Lecture



Scheduling: WFQScheduling: WFQ

• Variant of Fair Queueing:– share per bandwidth varies between flows; negotiated at

set-up– Possible implementation: (virtual clock)

• TimeStamp: each packet is associated with a timestamp that determines planed sending time

– first packet: connection setup time– other packets: increment timestamp by time difference that matches

the average negotiated bandwidth of the flow (act_Packetsize/bandwidth)

• what packets are sent first?– Inspect timestamps. Sent packets with minimum time first

– Advantage: individual bandwidth share per flow– Disadvantage: Overhead due to scheduling– WFQ guarantees minimal throughput and miximal delay

Status: Lecture



IP v 4 HeaderIP v 4 Header

• QoS in IP-Datagrams– Described by TOS-

Byte• Priority• Delay• Throughput• Reliability

– RFC 791: do not use TOS

– IPv4 can not provide QoS

4-bit version

4-bit hdrlength

8-bit type of serv.(TOS)

16-bit total length (in bytes)

16-bit identification3-bit flags

13-bit fragment offset

8-bit time to live(TTL)

8-bit protocol 16-bit header checksum

32-bit source IP address

32-bit destination IP address

Options (if any)

data

Prio DelayTP Rel CU CU

Status: Lecture



Changes to Ipv4: Changes to Ipv4: • 128 bit addresses (so we don't 128 bit addresses (so we don't

run out of IP addresses) run out of IP addresses) • header simplification (faster header simplification (faster

processing) processing) • more support for type of service more support for type of service

– priorities priorities – flow identifier: identifiy packets flow identifier: identifiy packets

in a connection in a connection

• securitysecurity Notes: Notes: • no fragmentation in network no fragmentation in network

– packet too big generates ICMP error to source packet too big generates ICMP error to source – source fragmentation via extension header source fragmentation via extension header

• no checksum (already done at transport and data link layer) no checksum (already done at transport and data link layer)

IPv6IPv6DS field (DiffServ)

Status: Lecture



AgendaAgenda


Status: Lecture



Integrated Services ModelIntegrated Services Model

Layer 3

Layer 2

RSVPIntServ

ISSLL

3 Working Groups

Status: Lecture



IntServ ArchitectureIntServ Architecture

• RSVP (Resource Reservation Protocol)– Generic Mechanisms– Dynamic, per flow– p-2-p and multicast

• IntServ (Integrated Services)– Layer 3 in each entity– classes of service for each flow

• Guaranteed• Controlled Load• Best Effort

Status: Lecture




• ISSLL (Integrated Services over a Specific Link Layer)– ISSLOW (Slow Links)

• Header Compression• Priority Packets

– IS802• uses 802.1p tagging

– ISATM• ATM QoS

– If no Definition for link layer• Layer 3 packet scheduling

Status: Lecture




• What IntServ does NOT:– provide packet forwarding or format specification

• still IPv4, IPv6

– routing• no QoS routing

– Admission control in the network• if not enough resources, use best effort class

Status: Lecture



Internet signaling transport: Internet signaling transport: RSVPRSVP

• Main motivation is to efficiently support multipoint multicast with resource reservations– large numbers of heterogeneous receivers – heterogeneity in available bandwidth to receiver – heterogeneity in receiver QoS demands (differing

delay requirements) • Progression

– Unicast– Naive multicast– Intelligent multicast– Naive multipoint multicast– RSVP

Status: Lecture



RSVP in shortRSVP in short

• Host-network-host Signaling Protocol– who am I? (user ID, application ID)– how can you recognize my packets? – what do I want? (service type, quantity)– what part of the network will I impact?

• Useful for any persistent traffic flows– quantitative (Intserv)– qualitative

• Admission control and topology awareness enable stricter guarantees

• Unifies other QoS mechanisms

Status: Lecture



RSVPRSVP

• When no reservation is needed, no change to internet• Receiver initiated

– scalability – heterogeneity, each receiver chooses IntServ class

• Reservation state per group, instead of per connection• PATH and RESV messages• PATH sets up next hop towards source(s)

– no reservations at this point

• RESV makes reservation• Travel as far back up as necessary

– how does receiver know of success?• DSBM: Designated Subnet Bandwidth Manager for 802 type

networks

Status: Lecture



Filters and Soft StateFilters and Soft State

• Filters – Allow receivers to separate reservations– Fixed filter

• receive from exactly one source

– Dynamic filter• dynamically choose which source is allowed to use

reservation

• Soft State– State in switch controllers (routers) is

periodically refreshed– On a link failure, automatically find another route– will go away if not "refreshed" by receivers

Status: Lecture



Sender sends Tspec out on multicast tree in PATH message

Receiver sends RESV message back up tree:

• contains senders Tspec and receiver QoS requirement (Rspec)

• routers along reverse path reserve resources needed to satisfy receiver's QoS

Call Setup in RSVPCall Setup in RSVP

Sender

Receiver 1

R4

R2

R3

R5R1

Path

RESV

Status: Lecture



RSVP: Multicast

Multiple receivers: • may have different QoS requirements • resource reservations merged as RESV travels

upstream • resources must be allocated to satisfy strictest

demands of downstream receivers – e.g.: receiver 1 first reserves resources for 100

ms max delay – if receiver 2 QoS is 200 ms max delay, no new

resources at R2, R1 – if receiver 2 QoS is 50 ms, more resources

needed at R2, R1

Status: Lecture



Multiple ReceiversMultiple Receivers

Sender

Receiver 1

R4

R2

R3

R5R1

RESVReceiver 2

RESV

RESV(merged)

Status: Lecture



Multiple SendersMultiple Senders

Can handle multiple senders as well: – different "styles" of resource reservation

• e.g., reserve enough resources in case all senders simultaneous

• resource enough resources for two simultaneous senders

• can dynamically determine which of N streams is forwarded downstream (switching within the network)

Status: Lecture



Example Data Handling & RSVP SignalingExample Data Handling & RSVP Signaling

SwitchedNetwork

(in-house)

SmallRoutedNetwor

k(ISP)

LargeRoutedNetwork(Core)

ATMNetwork

End-to-end RSVP signaling

Sender

Receiver

Status: Lecture



RSVP DrawbacksRSVP Drawbacks

• QoS guarantees– every router has to use RSVP and Resource

Reservation

• Scalability– Context per flow in each router, even if no reservation

is requested• the RESV message must follow the same path than the

PATH message• Internet Routing is asymetrical

– per packet classification in router

Status: Lecture



Renegotiation problemsRenegotiation problems

• Static descriptors don’t make sense for interactive sources or multiple-time scale traffic

• Renegotiation matches service rate to traffic• Renegotiation is not free- incurs a signaling

overhead • Open questions

– when to renegotiate?– how much to ask for?– admission control?– what to do on renegotiation failure?

Status: Lecture



AgendaAgenda


Status: Lecture



Differentiated Services ModelDifferentiated Services Model

Edge Router (Ingress)• verify conformance (shape/tag/drop)• assigns label to packet

DiffServ Cloud

Receiver

Sender• establishes TOS• can control bitrate to assure QOS

Edge Router

(Egress)

• Better than Best Effort• In-Band Signalling (Packet Header)• Complexity shifted towards Edge Router• Simple Charging (Service Level Agreement)

Status: Lecture



DiffServ in shortDiffServ in short

• Aggregate traffic handling mechanism• Defines a small number of per-hop behaviours

(PHBs) supported in routers– invoked by per-packet marking

• Concatenation of ‘hops’, with admission control, can provide useful services across the DiffServ cloud

• Very scaleable– no inherent signaling– little state required

Status: Lecture



Class-based QoS• Internet model requires per session state at each router

– 1000s - 1000000s of flows

• reluctance on part of network admins to accept

• Differentiated service model: 3+ classes– Premium service:

• high scheduling priority - aggregate peak rate allocation - low delay

– Assured service: • high buffer priority => lower loss

– Best effort service: • the usual

Status: Lecture



DiffServ classes RFC 2597, 2598DiffServ classes RFC 2597, 2598

Service class Short Name DSCP ControlledPremium Service (Expedited Forwarding) EF 101110 YesHigh Priority HP 111000 NoPriority P 100000 NoBest Effort BE 000000 NoAssured Service Class 1 Drop Prec Low AF11 001010 NoAssured Service Class 1 Drop Prec Medium AF12 001100 NoAssured Service Class 1 Drop Prec High AF13 001110 NoAssured Service Class 2 Drop Prec Low AF21 010010 NoAssured Service Class 2 Drop Prec Medium AF22 010100 NoAssured Service Class 2 Drop Prec High AF23 010110 NoAssured Service Class 3 Drop Prec Low AF31 011010 NoAssured Service Class 3 Drop Prec Medium AF32 011100 NoAssured Service Class 3 Drop Prec High AF33 011110 NoAssured Service Class 4 Drop Prec Low AF41 100010 NoAssured Service Class 4 Drop Prec Medium AF42 100100 NoAssured Service Class 4 Drop Prec High AF43 100110 No

Higher Drop Precedence dropped first

Gold

Bronze

Silver

Status: Lecture



DSCP FiledDSCP Filed

• DS field = ex-Tos Field for IPv4 (rfc 791) • Traffic Class octet for IPv6

• --> DS field both in IPv4 and IPv6 header

• DSCP : Differentiated Service Code Point = 6 bits• CU: Currently Unused = 2 bits

DSCPDSCP CUCUDS DS fieldfield

IP Precedence

Status: Lecture



Differentiated ServicesDifferentiated Services

PHB: Per Hop BehaviorPHB: Per Hop Behavior• Congestion-MgmtCongestion-Mgmt• Queuing+SchedulingQueuing+Scheduling > RED, WFQ,...> RED, WFQ,...

PHB: Per Hop BehaviorPHB: Per Hop Behavior• Congestion-MgmtCongestion-Mgmt• Queuing+SchedulingQueuing+Scheduling > RED, WFQ,...> RED, WFQ,...

CORECORECORECOREEDGEEDGEEDGEEDGE EDGEEDGEEDGEEDGE

Simple Simple TasksTasks

Simple Simple TasksTasks ComplexComplex

TasksTasksComplexComplex

TasksTasks

Traffic Traffic Classification,Classification,

Policing, Policing, ShapingShaping

Traffic Traffic Classification,Classification,

Policing, Policing, ShapingShaping

DataDSCP

Status: Lecture



DiffServ Architecture (simplified)DiffServ Architecture (simplified)

• Classifier– Behavior Aggregate (BA): only DSCP

(index into PHB table). Policy dictates configuration of PHB

– Multifield (MF), other header info (Port, Protocol, DA, SA)

• Marker– add DSCP if empty– add DSCP as mapped from RSVP-

Params– map DSCP <-> IP-TOS– change DSCP according to local policy– can apply traffic shaping

• Meter– statistics

• Conditioner– applies PHB– queue selection and

treatment– policing– packet dropping– authentication for Admission

Control

Marker

IP packetsclassifier

Meter

ConditionerBackbone

Edge

Status: Lecture



Service Level Agreement (SLA)Service Level Agreement (SLA)

• SLA– between border networks– defines traffic profile– establishes policy criteria– traffic will be policed and smoothed at egress points

according to the SLA– “out of profile” traffic at ingress point have no

guarantees

Status: Lecture



TradeOffTradeOff

• QoS mechanisms range in complexity– processing overhead– state overhead– not referring to complexity of usage here

• Generally, at a given level of complexity, the network administrator can tradeoff:– efficiency with which network resources are used– strictness (tightness) of QoS guarantees

Status: Lecture



AgendaAgenda


Status: Lecture



MotivationMotivation• Stream Tailoring as QoS enforcement

mechanism– to match different receivers QoS

req.• processing power• network connection properties

– match different receivers vis. req.• temporal domain• spatial domain• frequency domain• combinations/transcoders• error resilience (seg./re-assembly)

– influences Bandwidth– influences QoS– Different Scenarios

• VoD• Realtime Conferences

Temporal Filtering

Spatial Filtering

Frequency Filtering

Combi Filtering

Status: Lecture



QoS related TasksQoS related Tasks

• Support– quality enhanced multimedia communication using a QoS-

Framework

– Multicast scenarios

– Mobility (Session-Mobility)

– Adaptivity (Transparent vs. Adaptive)

– Heterogenity (end hosts, network characteristics

– Fairness-Policies (IETF Policy Framework)

– simple, yet powerful API (QoS-API)

– different media qualities (Videoconference vs. S-VHS)

• Use networkspezific QOS Mechanisms

• media stream adaptation in network and end hosts

• user friendly interface for QoS specification

Status: Lecture



Adaptive QoS MiddlewareAdaptive QoS Middleware

Adaptive EndsystemAdaptive Services

QoS Requirement

QoS Specification

Distributed QoS Architecture • Mobility• Adaptivity• Heterogenity

QoSMonitoring

QoS Mechanisms/Negotiation

Application

Active Netwerk, provides QoS (IntServ, DiffServ,...) and Adaptation

ProtocolLayers

NetworkSubsystem

Media Processors

Qo

S-M

ana

gem

ent

User

Application

ProtocolLayers

NetworkSubsystem

Media Processors

Qo

S-M

ana

gem

ent

User

Adaptive EndsystemAdaptive Services

Status: Lecture



QoS in mobile networks + FilteringQoS in mobile networks + Filtering

Main goal: support adaptive media streaming given soft end-to-end QoS

requirements

adaptive media filtering, media scaling and media transcoding at the end-systems and inside the net under given QoS requirements

to serve heterogeneous and moving receivers

Objectives: FAST (real-time streaming) Scalable System (support several users simultaneously) Scalable Bandwidth Adaptation (wireless + wired users) Support for broad range of adaptation mechanisms (different QoS wishes) Configurable (for different receivers and scenarios) Chainable (Filterchain) Robust (protect wireless transmission if desired)

Filters bridge Heterogenity Gap inherent to Wireless Communication

Status: Lecture



Usage ScenarioUsage Scenario

Base Station

VoD ServerRouter

1.436 mbpsfull quality

1.436 mbps full quality

F

1.182 mbps lower Quality

F78 kbps

FFF

78 kbps

36 kbps

32.2 kbps

25.2 kbps

78 kbps

78 kbps

QQ

Q

QQ

Q

Q

Q

Q

Q Q

QQoS Framework

FMedia Filter

Mobile Subnet with Wireless Proxy Server • Multimedia Adaptation Services

• Error Control (local re-transmit)• Policy-Control

Core-Net

QPolicyServer

Q

Admission Control

Q

Wireless Proxy ServerF

F

F

ip qos issues

Documents