Appunti di Multimedia Internet

Multimedia Internet

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, leading to the birth of QoS. QoS is defined in terms of the 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 as 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 information lost are retrieved.

1. TCP understands the loss of packet and is semantically transparent (the order is not touched).
2. TCP tries to apply congestion control with 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 (as long as the playout buffer depth). Network introduces delay in delivery of packets.

Performance of a playback application is measured with 2 factors:

• Latency
• Fidelity

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

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 applications are served with guaranteed network service:

• High cost, high quality intolerant applications with hard threshold

Parameters: Threshold (T). Tolerant applications are served with statistical service (or predictive):

• Low cost, all retail applications with 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.

QoS application

The division on real time and non-real time applications usually doesn’t consider if the application is data, audio, or video. Some type of applications we can find in a network are the following:

Sample delay-oriented SLA

Based on Olympic Services defined statistically:

• Gold: 90 ms, probability of exceeding 0.001
• Silver: 120 ms, probability of exceeding 0.001
• Bronze: 250 ms, probability of exceeding 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 exceeds 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
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 okay.

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 measure is removed

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 packets
3. N is the number of ping packets with delay D>d
4. 11 < 4) is the condition not to violate SLA

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 actions can be taken 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

Traffic Condition Agreement parameters

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 a bit rate
• Maximum length of packets
• Minimum length of packets

After TCA and SLA are established, the traffic is examined by a regulator, which splits IN traffic and OUT traffic. We can have different types of regulators, depending on 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 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 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 by modifying one byte on the 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 measure 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, and is referred to as token bucket size. The 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 the 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 the buffer is not empty and/or the counter is null, incoming traffic is buffered. When the input buffer is not empty, one traffic unit is fetched from the 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 the token counter is full, it must stop and wait for 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 on 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 it doesn’t exceed CBS
• Yellow if it exceeds CBS but doesn’t exceed EBS
• Red otherwise CBS < EBS

Meter operating modes

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

Token counts are updated CIR times per second in the following way:

• If T < CBS, Tc is incremented by one;
• If T < EBS, Te is incremented by one;
• Neither T nor T are incremented.

When a packet of size B bytes arrives:

• If T (t) – B ≥ 0, the packet is green; decrement T (t) by B tokens;
• If T (t) – B ≥ 0, the packet is yellow, decrement T (t) by B tokens;
• Else the packet is red.

SRTCM operating in color aware mode

When a packet of size B bytes arrives:

• If the packet has been precoloured as green && T (t) – B ≥ 0, the packet is green; T is decremented by B;
• If the packet has been precoloured as green or yellow && T (t) – B ≥ 0, the packet is yellow; Te is decremented by B;
• Else the packet is red and neither T nor Te is 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
• PB: Peak Burst Size [bytes]. Maximum size of token bucket P

TRTCM operating in color blind mode

When a packet of size B bytes arrives:

• If T (t) – B < 0, the packet is red;
• If Tc(t) – B < 0, the packet is yellow and T is decremented by B;
• Else the packet is green and both T and T are decremented by B.

TRTCM operating in color aware mode

When a packet of size B bytes arrives:

• If the packet has been precoloured as red || T (t) – B < 0, the packet is red;
• If the packet has been precoloured as yellow || T (t) – B < 0, the packet is yellow and T is decremented by B;
• Else the packet is green and both T and T are decremented by B.

This time constraint curve is no longer linear, it is piecewise linear and is able to enforce two rates, peak rate and average rate.

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 the transmission of a packet is over, the service class to be served next. Backplane: critical component, must be very fast.

Buffer requirements in a scheduler

How many buffers do I need to have in a scheduler? It depends on 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.