Appunti di Multimedia Internet

Multimedia Internet

1. QUALITY OF SERVICE (QOS) IN IP NETWORKS

Resources can be public or private

→

Public resources shared bandwidth

First solution was Best Effort (by ARPANET) →

With Real Time Services (web 2.0) Best Effort was not enough Born of QoS

QoS is defined in term of percentage time the connection works .

On this base Client-Telco make an agreement (SLA) based on percentage availability:

• Availability

• System perimeter of availability

• Availability level for each interface

• Procedure to measure availability

• Penalties

Multimedia applications are sensitive both to delay and packet loss, in addition to availability.

QOS IN MULTISERVICE IP NETWORKS

Items we may find in the SLA are

• Availability

• Delay (packet)

• Throughput (packet or bytes per second)

• Packet loss rate

• Packet sequence inversion

• Delay variation

Quality of some types of application depends on delay and/or packet loss. These applications are

classified in Real-time and Elastic applications

Elastic Application (web browsing, file transfer, e-mail)

Applications more robust against delay and admit retransmissions, data are waited till they arrive.

TCP can be used and all informations lost are retrieved.

1) TCP understands the loss of packet and is semantically transparent (the order is not

touched). →

2) TCP try to apply congestion control Congestion window

Real Time Application (telephony, video streaming, multivideo conferencing)

A packet arriving after a given delay threshold is useless; also retransmission is useless

Important are playback applications: source takes some signal, packetizes it, transmits some

packets over the network, with the help of playout buffer (with as length the playout buffer

depth). Network introduces delay in deliver of packet.

Diagram reproduction-time and playback point

Trade off playout buffer length – delay

→

Network speed > reproduction speed accumulation of bytes in buffer

→

Reproduction speed > network speed depletion of buffer

Buffer underflow happens when reproduction speed is for long time greater than network speed.

Performance of a playback applications is measured with 2 factors:

• Latency

• Fidelity

Some application are rather sensitive to the first or the second, others are not.

There exists cases of no multiservice network, and example is High Frequency Trading (HFT).

Real time playback applications can be:

• →

Tolerant (buffer underflows are admitted) Audio and video applications

• →

Intolerant (no buffer underflows) Pseudowire applications

Pseudowire needs to guarantee zero buffer underflow, using a fixed offset delay

Intolerant application are served with guaranteed network service:

High cost High quality intolerant applications Hard threshold

Parameters: Threshold (T)

Tolerant application are served with statistical service (or predictive)

Low cost All retail applications Soft threshold

Parameters: Threshold, probability to overpass the threshold (T,p)

Third service is best effort

Anything can happen,

Sharing of resources inside a multiservice IP network

Non playback applications are for example online gaming

QoS Application

The division on real time and non real time applications usually doesn’t consider if application is

data, audio or video.

Some type of applications we can find in a network are the following:

Application Description Tolerance to

delay

Telephony (IP) Real time, playback, statistical service Very low

Circuit emulation (Pseudowire) Real time, playback, guaranteed service No

Multimedia conference Statistical service Low

Real time interactive Real time, non playback, statistical service Low

Multimedia streaming Real time, playback, statistical service Tolerant

Broadcast video Real time, playback, statistical service Low

Low latency data Statistical service Tolerant

Low priority data Best effort service Tolerant

Network control Control delay Tolerant

Signaling Light traffic but control delay Tolerant

O & M Light traffic but control delay Tolerant

Sample Delay-Oriented Sla

Based on Olympic Services defined statistically:

Service Delay Probability of exceeding

Gold 90 ms 0.001

Silver 120 ms 0.001

Bronze 250 ms 0.001

Also Best effort service is provided, but no SLA is assigned to this service.

A maximum delay d is fixed

A maximum fraction p of packets can be allowed to exceed the delay threshold d.

Actual delay is defined as D Pr( )

> <

So SLA is defined as:

A delay distribution can be defined and plotted, based

on delay D.

When D exceed the limits d, the distribution doesn’t

respect the request and is the area under curve f(D),

from d to infinity: ∞

Pr( ) ( )

> =

∫

Implementation of statistical delay occurs in the

following way:

• →

d, p SLA is defined

• SLA must be measured on the working system

• Periodically a summary evaluation of SLA is exchanged between client and provider

• The client can decide if he received the agreed SLA

Different methods can be proposed to measure quality given a SLA (d,p):

1) Every Δt (s) and end-to-end ping packet is sent to measure delay

2) D becomes the delay of the i-th packet

i

3) T is defined as the measurement period; N=T/Δt is the number of measured ping packets

4) Delay is calculated with the following formula:

1 ∑

=

=1

5) If Delay > d, SLA has been violated

However this method returns the average delay, so the maximum of the curve f(D): it has to be

always smaller than d, and SLA is always fulfilled. So this method is not ok.

A new method is proposed

1) Ping system as before

2) The 10% of highest delays is removed

3) If a delay D is measured when a link is in congestion, the meaure is removed

i

Also with this system the SLA is always fulfilled, being all the highest delays removed.

Proper way of measuring SLA (d,p) is the following:

1) Ping system as before

2) D is the delay of i-th ping packet; N is the number of ping packet

i

3) N is the number of ping packets with delay D>d.

1

1 <

4) is the condition not to violate SLA

2. TRAFFIC MANAGEMENT

QOS: BASIC BUILDING BLOCKS →

SLA is important but not sufficient Traffic Condition Agreement (TCA)

→

SLA target QoS the provider is committed to deliver to the customer

→

TCA upper limit to users traffic

• IN profile traffic

• OUT of profile traffic

SLA must meet conditions only for IN traffic, while a number of action can be done for OUT traffic

1. Policing: traffic is dropped

2. Shaping: traffic is delayed until it is possible

3. Marking: traffic is marked and offered to the network

TCA can include different parameters in order to characterize IN and OUT traffic:

→

P: Peak rate of traffic maximum value of the rate of the traffic

→

A: Average rate of traffic measured in long time window. P ≥ A.

→

B: Maximum length of burst maximum number of packets I can send at bit rate

Maximum length of packets

Minimum length of packets

After TCA and SLA are enstabilished, the traffic is examined

by a regulator, which splits IN traffic and OUT traffic.

We can have different types of regulator, depending the

number of logical flows created: two-colours regulator or

three-colours regulator.

Two colours regulator

Two colours policing traffic regulators:

OUT packets are dropped and don’t enter in the network. Only green traffic proceeds.

Two colours shaping traffic regulators:

OUT traffic is buffered in such a way it is transmitted in the network only when it is possible

without exceeding the TCA. Traffic entering in the network is always green.

Two colours marking traffic regulators:

OUT traffic is let to proceed, but marked, dropping its priority. Alternatively the SLA is

downgraded, till arriving as Best Effort.

Traffic is marked modifying one byte on packet header. We act on DSCP (Differentiated Services

→

Code Point) byte of the packet; 6 of the 8 bits are available, 2 are reserved 64 different services.

It is the router (classifier possibly) to stamp SLA into packets

A traffic regulator is made of:

1. Classifier

2. Meter

3. Actuators (shaper, dropper, marker)

A meter is used to meaure the traffic stream against a traffic profile. It can be implemented as a

token bucket. Token: permission to transmit 1 byte or 1 packet.

POLICER

Token bucket policer:

has a counter of tokens, with maximum value b, an is

referred to as token bucket size.

Token counter is increased every 1/r seconds, with r token rate.

One traffic unit (bit, byte, or packet) of offered traffic is allowed to pass

through the regulator if the counter is positive (then, the counter is

decremented).

Otherwise, if the counter is equal to zero, the traffic unit is dropped.

→ Traffic offered to network is linearly bounded. No delay but packet loss.

SHAPER

Token bucket shaper:

Token counter works as for the policer. If when a bit arrives the counter

is positive and the input buffer is empty, the bit passes. If buffer is not

empty and/or the counter is null, incoming traffic is buffered. When

input buffer is not empty, one traffic unit is fetched from buffer as soon

as a token is generated. Not more than r bit/s can be output. Parameter

b controls the length of output traffic burst. When token counter is full, it must stop and wait

further tokens.

→ No packet loss but presence of delay.

Constraint function of both these previous regulators is the line b+rt:

it represents the maximum number of traffic units, corresponding to

IN traffic, that the regulator lets pass into the network.

Excess traffic is OUT traffic, and how it is treated depends from the

regulator.

MARKER

Token bucket marker:

Works as a policer, but does not drop OUT traffic. It is marked and forwarded into the network.

→ Inside the network, as soon as congestion arises, marked packets are dropped before IN

packets.

Single rate three colours marker (SRTCM)

Parameters used are the following: →

CIR: Committed Information Rate [bit/s] green

→

CBS: Committed Burst Size [bit] yellow

→

EBS: Excess Burst Size [bit] red

A packet is marked:

• Green if doesn’t exceed CBS

• Yellow is it exceeds CBS but doesn’t exceed EBS

• Red otherwise CBS < EBS

Meter can operate in two different ways:

• →

Colour-blind mode Colours of input packets are not considered.

• →

Colour-aware mode Colours entry with a colour and then they can change.

Colour is coded in the DS field of the packet. So changing the colour of the packet, the treatment is

different (Per Hop Behaviour).

SRTCM operating in color blind mode

The two token buckets C and E share the same rate, CIR.

CBS: maximum size of token bucket C.

EBS: maximum size of token bucket E.

Initially C and E are full, so T (0) = CBS and T (0) = EBS.

C E

Token counts are updated CIR times per second in the

following way: →

o If T < CBS Tc is incremented by one;

C →

o If T < EBS Te is incremented by one;

E

o Neither T or T are incremented.

C E

When a packet of size B bytes arrives:

→

o If T (t) – B ≥ 0 packet is green; decrement T (t) by B tokens;

C C

→

o If T (t) – B ≥ 0 packet is yellow, decrement T (t) by B tokens;

E E

→

o Else packet is red.

SRTCM operating in color aware mode

When a packet of size B bytes arrives:

o If packet has been precoloured as green &&

→

T (t) – B ≥ 0 packet is green; T is decremented by B;

C C

o If packet has been precoloured as green or yellow &&

→

T (t) – B ≥ 0 packet is yellow; Te is decremented by B;

E →

o Else packet is red and neither T nor Te is

C

decremented.

Note that an input red packet stays red, a yellow can exit yellow

or red, a green can exit green, yellow or red.

Green packets: original SLA is guaranteed.

Yellow packets: packet loss priority increased and/or SLA decreased.

Red: drop and/or increase packet loss priority and/or SLA decreased.

Two rate three colours marker (TRTCM)

Parameters:

PIR: Peak Information Rate [byte/s]

CIR: Committed Information Rate [byte/s] PIR ≥ CIR

• Packet is green if it doesn’t exceed CIR.

• Packet is yellow if it exceeds CIR but not PIR.

• Packet is red if it exceeds PIR.

Also the following parameters are present:

CBS: Committed Burst Size [bytes]. Maximum size of token bucket C

PBS: Peak Burst Size [bytes]. Maximum size of token bucket P

→

T (t): number of tokens in C T (0) = CBS

C C

→

T (t): number of tokens in P T (0) = PBS

P P

TRTCM operating in color blind mode

When a packet of size B bytes arrives:

→

o If T (t) – B < 0 the packet is red;

P →

o If Tc(t) – B < 0 the packet is yellow and T is

P

decremented by B;

→

o Else packet is green and both T and T are

P C

decremented by B.

TRTCM operating in color aware mode

When a packet of size B bytes arrives: →

o If packet has been precoloured as red || T (t) – B < 0

P

packet is red;

o If packet has been precoloured as yellow || T (t) – B < 0

C

→ packet is yellow and T is decremented by B,

P

→

o Else packet is green and both T and T are

C P

decremented by B.

This time constraint curve is no more linear, is piecewise linear and is able to enforce two rates,

peak rate and average rate. 3. HOW TO GUARANTEE QOS

Traffic Contract

We have seen a traffic contract between a provider and a customer includes TCA and SLA.

TCA specifies the traffic profile.

SLA specifies the QoS requirements.

It’s important to guarantee QoS:

1. First step is negotiation of SLA and TCA (long time scale)

2. Second step is resource allocation and admission control (connection time scale)

3. Third step is the scheduling (packet time scale).

SCHEDULING

The scheduler organizes the transmission of packets by

choosing which service class has to be served and

selects, when transmission of packet is over, the service

class to be served next.

Backplane: critical component, must be very fast.

How many buffers do I need to have in a scheduler?

It depends from the architecture we choose:

• Per microflow architecture: managing the QoS

of each individual flow separately.

→ It requires one buffer per connection,

introducing scalability problems.

• Per macroflow architecture: microflows are

grouped in classes, building macroflows. We

manage service classes instead of individual flows.

→ It requires one buffer per service cl