Appunti di Multimedia Internet

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 class.

It is the connection we work with.

With macroflow connection, if incoming traffic requires similar services, it ends in the same buffer,

marked with the 6 bits inside the DSCP byte. So maximum we will have 64 different buffer, solving

the scalability problem.

Every scheduling will have a scheduling algorithm.

FIFO scheduler

Only 1 buffer, we can’t differentiate services.

Best Effort working, no guarantees on delay.

Clearly only one SLA can be offer to all the flows.

→ Inefficient

Strict Priority scheduler (SP)

When a packet needs to be selected to be served:

• →

If (queue 1 has packet) packet in queue 1 served

• →

Else if (queue 2 has packet) packet in queue 2 served

• →

Else if (queue 3 has packet) packet in queue 3 served

• →

Otherwise idle

Traffic with stringent QoS requirements will have highest

priority level (good for Pseudowire). Best Effort can be assigned to the lowest priority level

General Processor Sharing scheduler (GPS)

Each process has a weigth, ranging from 0 to 1; larger the

weigth, larger the time slice the process gets.

Sum of all the weigths is always 1.

ith service class receives at least a transmission capacity

equal to wC, where C is the link’s capacity.

→ Particular case: service class silent. In this case spare

capacity is distributed among the non-silent service classes,

proportionally to the weights.

If service category 3 is inactive: