Telematics 2 & Performance Evaluation Chapter 2 Quality of - - PDF document

1 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Telematics 2 & Performance Evaluation

Chapter 2

Quality of Service in the Internet

(Acknowledgement: These slides have been compiled from Kurose & Ross, and other sources)

2 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Improving QoS in IP Networks

Thus far: “making the best of best effort” Alternative way: next generation Internet with QoS guarantees

q RSVP: signaling for resource reservations q Differentiated Services: differential guarantees q Integrated Services: firm guarantees q Simple model

for sharing and congestion studies:

3 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Principles for QoS Guarantees (1)

q Example: 1Mbps IP phone, HTTP share 1.5 Mbps link.

q Bursts of HTTP can congest router, cause audio loss q Want to give priority to audio over HTTP

Packet marking needed for router to distinguish between different classes; and new router policy to treat packets accordingly Principle 1

4 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Principles for QoS Guarantees (2)

q What if applications misbehave (audio sends higher than declared

rate)

q Policing: force source adherence to bandwidth allocations q Marking and policing at network edge

Provide protection (isolation) for one class from others Principle 2

5 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Principles for QoS Guarantees (3)

q Allocating fixed (non-sharable) bandwidth to flow: inefficient use of

bandwidth if flows doesn’t use its allocation

While providing isolation, it is desirable to use resources as efficiently as possible Principle 3

6 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Principles for QoS Guarantees (4)

q Basic fact of life: cannot support traffic demands beyond link capacity

Call Admission: flow declares its needs, network may block call (e.g., busy signal) if it cannot meet needs Principle 4

7 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Summary of QoS Principles

Let’s next look at mechanisms for achieving this ….

8 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Scheduling And Policing Mechanisms

q Scheduling: choose next packet to send on link

q FIFO (first in first out) scheduling: send in order of arrival to queue q Real-world example?

q Discard policy: if packet arrives to full queue: which one to discard?

■ Tail drop: drop arriving packet ■ Priority: drop/remove on priority basis ■ Random: drop/remove randomly

9 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Scheduling Policies (1)

Priority scheduling: transmit highest priority queued packet

q Multiple classes, with different priorities q Class may depend on marking or other header info, e.g. IP

source/dest, port numbers, etc..

q Real world example? 1 3 2 4 5 5 5 2 2 1 1 3 3 4 4

arrivals departures packet in service 10 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Scheduling Policies (2)

Round robin scheduling:

q Multiple classes q Cyclically scan class queues, serving one from each class (if

available)

q Real world example? 1 2 3 4 5 5 5 2 3 1 1 3 2 4 4

arrivals departures packet in service

11 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Scheduling Policies (3)

Weighted Fair Queuing:

q Generalized Round Robin q Each class gets weighted amount of service in each cycle q Real-world example?

12 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Policing Mechanisms (1) Goal: limit traffic to not exceed declared parameters

Three commonly used criteria:

q (Long term) Average Rate: how many packets can be sent per unit

time (in the long run)

q Crucial question: what is the interval length: 100 packets per sec

• r 6000 packets per min have same average!

q Peak Rate: e.g., q 6000 packets per min. (ppm) average q 1500 packets per second peak rate q (Max.) Burst Size: max. number of pkts sent consecutively (with no

intervening idle)

13 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Policing Mechanisms (2) Token Bucket: limit input to specified Burst Size and Average Rate.

q Bucket can hold b tokens q Tokens generated at rate r token/sec unless bucket full q Over interval of length t: number of packets admitted less than or

equal to (r ⨉ t + b).

14 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Policing Mechanisms (3)

q Token bucket, WFQ combine to provide guaranteed upper bound

• n delay, i.e., QoS guarantee

WFQ

token rate, r bucket size, b

per-flow rate, R D = b/R max

arriving traffic arriving traffic

15 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

An Overview/Comparison of Proposed Approaches

What is it? hidden from end-user N (not network- wide) Label-Switching (circuit- building) Framework MPLS low N Priority framework Diff-Serv high with Int-Serv Reservation protocol RSVP high Y Reservation framework Int-Serv Complexity Usage guarantees QoS Name

16 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Integrated Services (IntServ)

q An architecture for providing QoS guarantees in IP networks for

individual application sessions

q Relies on resource reservation, and routers need to maintain state info

(like for a virtual circuit), maintaining records of allocated resources and responding to new call setup requests

• n that basis

Question: Can newly arriving flow be admitted with performance guarantees while not violating QoS guarantees made to already admitted flows?

17 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

IntServ: QoS Guarantee Scenario

q Resource reservation q Call setup, signaling (RSVP) q Traffic, QoS declaration q Per-element admission control q QoS-sensitive scheduling (e.g., WFQ)

request/ reply

18 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Call Admission Arriving session must :

q Declare its QoS requirement q R-spec: defines the QoS being requested q Characterize traffic it will send into network q T-spec: defines traffic characteristics q Signaling protocol: needed to carry R-spec and T-spec to routers

(where reservation is required)

q RSVP (Resource Reservation Protocol)

19

IntServ QoS: Service Models (1)

q Guaranteed service: q Worst case traffic arrival: leaky-

bucket-policed source

q Simple (mathematically

provable) bound on delay [Parekh 1992, Cruz 1988]

Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Controlled load service:

q “A quality of service closely

approximating the QoS that same flow would receive from an unloaded network element.” WFQ

token rate, r bucket size, b

per-flow rate, R D = b/R max

arriving traffic

[RFC 2211, RFC 2212] 20 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

IntServ QoS: Service Models (2)

q Guaranteed QoS

q Provides with firm bounds on queuing delay at a router; q Envisioned for hard real-time applications that are highly sensitive to end-

to-end delay expectation and variance

q Controlled Load

q Provides a QoS closely approximating that provided by an unloaded router q Envisioned for today’s IP network real-time applications which perform well

in an unloaded network

21 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Call Admission

q Call Admission: routers will admit calls based on their R-spec and T-

spec and based on the current resource allocated at the routers to

• ther calls.

22 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

T-Spec

q Defines traffic characteristics in terms of q Leaky bucket model (r = rate, b = bucket size) q Peak rate (p = how fast flow might fill bucket) q Maximum segment size (M) q Minimum segment size (m) q Traffic must remain below M + min(pT, rT+b-M) for all possible times T q M instantaneous bits permitted (pkt arrival) q M + pT: can’t receive more than 1 pkt at rate higher than peak rate q Should never go beyond leaky bucket capacity of rT+b

23 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

R-Spec

q Defines minimum

requirements desired by flow(s)

q R: rate at which packets may

be fed to a router

q S: the slack time allowed

(time from entry to destination)

q Modified by router

■ Let (Rin, Sin) be values

that come in

■ Let (Rout, Sout) be values

that go out

■ Sin – Sout = max time

spent at router

q If the router allocates buffer size

β to flow and processes flow pkts at rate ρ then

q Rout = min(Rin, ρ) q Sout = Sin – β/ρ

q Flow accepted only if all of the

following conditions hold

q ρ ³ r (rate bound) q β ³ b (bucket bound) q Sout > 0 (delay bound) 24 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Call Admission for Controlled Load

q A more flexible paradigm

q does not guarantee against losses, delays q only makes them less likely

q Only T-Spec is used

q routers do not admit more than they can handle over long timescales q short time-scale behavior unprotected (due to lack of R-Spec)

q In comparison to QoS-Guaranteed Call Admission

q more flexible admission policy q looser guarantees q depends on application’s ability to adapt

■ handle low loss rates ■ cope with variable delays / jitter

25 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Scalability: Combining T-Specs

q Problem: Maintaining state for every flow is very expensive q Solution: combine several flows’ states (i.e., T-Specs) into a single

state

q Must stay conservative (i.e., must meet QoS requirements of the flows) q Several models for combining

■ Summing: all flows might be active at the same time ■ Merging: only one of several flows active at a given time (e.g., a

teleconference)

26 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Combining T-Specs

q Given two T-Specs (r1, b1, p1, m1, M1) and (r2, b2, p2, m2, M2) q The summed T-Spec is

(r1+r2, b1+b2, p1+p2, min(m1,m2), max(M1,M2))

q The merged T-Spec is

(max(r1,r2), max(b1,b2), max(p1,p2), min(m1,m2), max(M1,M2))

q Merging makes better use of resources

q Less state at router q Less buffer and bandwidth reserved q But how to police at network edges? q And how common?

q Summing yields a tradeoff

q Less state at router q What to do downstream if flows split directions downstream?

27 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Resource Reservation Protocol (RSVP)

q Int-Serv is just the network framework for bandwidth reservations q Need a protocol used by routers to pass reservation info around q Resource Reservation Protocol

q Is the protocol used to carry and coordinate setup information (e.g., T-

SPEC, R-SPEC)

q Designed to scale to multicast reservations as well q Receiver initiated (easier for multicast) q Provides scheduling, but does not help with enforcement q Provides support for merging flows to a receiver from multiple sources

• ver a single multicast group

28 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

RSVP Merge Styles

q No Filter: any sender can utilize reserved resources

q E.g., for bandwidth:

S1 S4 S3 S2 No-Filter Rsv R1 R2

29 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

RSVP Merge Styles

q Fixed-Filter: only specified senders can utilize reserved resources

S1 S4 S3 S2 Fixed-Filter Rsv: S1,S2 R1 R2

30 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

RSVP Merge Styles

q Dynamic Filter: only specified senders can use resources

q Can change set of senders specified without having to renegotiate details

• f reservation

S1 S4 S3 S2 Dynamic-Filter Rsv S1,S2 Change to S1,S4 R1 R2

31 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

The Cost of Int-Serv / RSVP

q Int-Serv / RSVP reserve guaranteed resources for an admitted flow q Requires precise specifications of admitted flows

q If over-specified, resources go unused q If under-specified, resources will be insufficient and requirements will not

be met

q Problem: often difficult for apps to precisely specify their requirements

q May vary with time (leaky-bucket too restrictive) q May not know at start of session

■ e.g., interactive session, distributed game

32 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Measurement-Based Admission Control (MBAC)

q Idea:

q Applications don’t need strict bounds on delay, loss – can adapt q Difficult to precisely estimate resource requirements of some applications

q Flow provides conservative estimate of resource usage (i.e., upper

bound)

q Router estimates actual traffic load used when deciding whether there

is room to admit the new session and meet its QoS requirements

q Benefit: flows need not provide precisely accurate estimates, upper

bounds o.k.

q Flow can adapt if QoS requirements not exactly met

33 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

MBAC example (1)

q Traffic is divided into classes,

q Where class k does not affect class i for k > i

q Token bucket classification (Bi, Ri) q Let Dk be class k’s expected delay

q Only lower classes affect delay

k k-1

q Dk = S Bi / (μ - S Ri) (this is Little’s Law)

i=1 i=1

q Router takes estimates, dk and rk, of class k’s delay and rate q Admission decision:

q Should a new session (β, ρ) be admitted into class k? 34 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

MBAC example (2)

q New delay estimate for class j is

j-1

q dj + β / (μ - S ri) (bucket size increases)

i=1

q New delay estimate for class k > j is

k-1 k-1 k-1

dk (μ - S ri) / (μ - S ri - ρ) + β / (μ - S ri - ρ)

i=1 i=1 i=1

delay shift due to increase in aggregate reserved rate delay shift due to increase in bucket size

35 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Problems with Int-Serv / Admission Control

q Lots of signalling

q Routers must communicate reservation needs q Reservation done on a per-session basis

q How to police?

q Lots of state to maintain q Additional processing load / complexity at routers

q Signaling and policing load increases with increased # of flows q Routers in the core of the network handle traffic for thousands of flows

Conclusion: Int-Serv approach does not scale!

36 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

IETF Differentiated Services (DiffServ)

Intended to address the following difficulties with Intserv and RSVP;

q Scalability: maintaining states by routers in high speed networks is

difficult due to the very large number of flows

q Flexible Service Models: Intserv has only two classes, want to

provide more qualitative service classes; want to provide ‘relative’ service distinction (Platinum, Gold, Silver, …)

q Simpler signaling: (than RSVP) many applications and users may

• nly want to specify a more qualitative notion of service

37 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Differentiated Services

q Approach:

q Only simple functions in the core, and relatively complex functions at edge

routers (or hosts)

q Do not define service classes, instead provides functional components

with which service classes can be built End host End host core routers edge routers

38 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

DiffServ Architecture Edge router:

❑ per-flow traffic management ❑ marks packets as in-profile and

• ut-profile

Core router:

❑ per class traffic management ❑ buffering and scheduling ❑ based on marking at edge ❑ preference given to in-profile

packets

❑ Assured Forwarding

scheduling

. . .

r b marking

39 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Edge-Router Packet Marking

q Class-based marking: packets of different classes marked differently q Intra-class marking: conforming portion of flow marked differently

than non-conforming one

q Profile: pre-negotiated rate A, bucket size B q Packet marking at edge based on per-flow profile

Possible usage of marking:

User packets Rate A B

40 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Classification and Conditioning

May be desirable to limit traffic injection rate of some class:

q User declares traffic profile (eg, rate, burst size) q Traffic metered, shaped if non-conforming

41 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Classification and Conditioning

q Packet is marked in the Type of Service (TOS) in IPv4, and Traffic

Class in IPv6

q 6 bits used for Differentiated Service Code Point (DSCP) and

determine PHB that the packet will receive

q 2 bits are currently unused

42 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Edge Functions

q At DS-capable host or first DS-capable router

q Classification: edge node marks packets according to classification rules

to be specified (manually by admin, or by some TBD protocol)

q Traffic Conditioning: edge node may delay and then forward or may

discard

43 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

DiffServ Reservation Step

q DiffServ’s reservations are done at a much coarser granularity than

with IntServ

q Edge-routers reserve one profile for all sessions to a given destination q Renegotiate profile on longer timescale (e.g., days) q Sessions “negotiate” only with edge to fit within the profile

q Compare with IntServ

q Each session must “negotiate” profile with each router on path q Negotiations are done at the rate in which sessions start 44 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Core Functions

q Forwarding: according to “Per-Hop-Behavior” or PHB specified for the

particular packet class;

q Strictly based on class marking q Core routers need only maintain state per class

q BIG ADVANTAGE: No per-session state info to be maintained by core

routers!

q I.e., easy to implement policing in the core (if edge-routers can be trusted)

q BIG DISADVANTAGE: Can’t make rigorous guarantees

45 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Forwarding (PHB)

q PHB result in a different observable (measurable) forwarding performance

behavior

q PHB does not specify what mechanisms to use to ensure required PHB

performance behavior

q Examples:

q Class A gets x% of outgoing link bandwidth over time intervals of a specified length q Class A packets leave first before packets from class B

PHBs being developed:

q Expedited Forwarding:

q Forwarding treatment for one particular diffserv aggregate where the departure rate

• f the aggregate's packets from any diffserv node must equal or exceed a

configurable rate.

q The EF traffic SHOULD receive this rate independent of the intensity of any other

traffic attempting to transit the node

q Assured Forwarding: 4 classes of traffic

q where each AF class is in each DS node allocated a certain amount of forwarding

resources (buffer space and bandwidth)

q each AF class with three drop preference partitions

46 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Queuing model of EF

q Packets from various classes enter same queue q Denied service after queue reaches threshold q E.g., 3 classes: green (highest priority), yellow (mid), red (lowest

priority)

red rejection-point yellow rejection-point

47 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Queuing model of AF

q Packets into queue based on AF class q Each AF class gets a minimum rate q E.g., with 3 AF classes

48 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Comparison of AF and EF

q EF Properties:

q Higher priority class completely unaffected by lower class traffic

q AF Properties:

q Traffic of one AF class cannot use buffer of another AF class, even when

this class's buffer has room

49 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Differentiated Services Issues

q Impact of crossing multiple ASs and routers that are not DS-capable q Diff-Serv is stateless in the core, but does not give very strong

guarantees

q Q: Is there a middle ground (stateless with stronger guarantees)

50 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Dynamic Packet State (DPS)

q Goal: provide Int-Serv-like guarantees with Diff-Serv-like state

q E.g., fair queueing, delay bounds q Routers in the core should not have to keep track of individual flows

q Approach:

q Edge routers place “state” in packet header q Core routers make decisions based on state in header q Core routers modify state in header to reflect new state of the packet

51 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

r2 > b

DPS Example: fair queuing

q Fair queuing: if not all flows “fit” into a pipe, all flows should be

bounded by same upper bound, b

q b should be chosen so that pipe is filled to capacity

S1 S2 S3 b b r3

52 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

DPS: Fair Queuing

q The header of each packet in flow fi indicates the rate, ri of its flow into

the pipe

q ri is put in the packet header q The pipe estimates the upper bound, b, that flows should get in the

pipe

q If ri < b, packet passes through unchanged q If ri > b:

q packet is dropped with probability 1 - b / ri q ri replaced in packet with b (flow’s rate out of pipe)

q Router continually tries to accurately estimate b

q buffer overflows: decrease b q aggregate rate out less than link capacity: increase b

53 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Summary

q Int-Serv:

q Strong QoS model: reservations q Heavy state q High complexity reservation process

q Diff-Serv:

q Weak QoS model: classification q No per-flow state in core q Low complexity

q DPS:

q Middle ground q Requires routers to do per-packet calculations and modify headers q What can / should be guaranteed via DPS?

q No approach seems satisfactory

54 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Current State of Discussion

q IntServ Lost

q Too much state and signaling made it impractical q unable to accurately quantify apps’ needs in a convenient manner

q DiffServ is losing

q Not clear what kind of service a flow gets if it buys into premium class q What / how many / when should flows be allowed into premium unclear q What happens to flows that don’t make it into premium

q The current winner: over-provisioning

q Bandwidth is cheap these days q ISPs provide enough bandwidth to satisfy needs of all apps

55 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS

Reflection: Is over-provisioning the answer?

q Q: are you happy with your Internet service today? q Problem: the peering points between ISPs q Some traffic must travel between ISPs q Traffic crosses peering points q ISPs have no incentive to make other ISPs look good, so they do

not overprovision at the peering point

q Solutions: q ISPs duplicate content and buffer within their domain q What to do about live / dynamically changing content? q Will there always be enough bandwidth out there? q What is the next killer app? q Q: Are there other alternatives outside of the IP model?