On Transport Layer Mechanisms for Real-Time Application QoS 8 December 2005 Panagiotis Papadimitriou { [email protected] } ComNet Lab Demokritos University

On Transport Layer Mechanisms for Real-Time Application QoS

8 December 2005

Panagiotis Papadimitriou{ [email protected] }

ComNet LabDemokritos University of Thrace

Xanthi, GREECE

ComNet Lab - 8 December 2005

Contents

IntroductionIntroduction

Real-time streaming requirements State-of-the-art transport mechanisms

Real-time Performance Metric

Performance of MPEG-4 video delivery / VoIP

Scalable Streaming Video Protocol (SSVP)

Real-time streaming with TCP over satellite links


Introduction

A highly determinant feature of the Internet is its heterogeneity.

Basic parameters of heterogeneity:

Application Domain:

Traditional Applications (e.g. HTTP, FTP) Real-Time Applications (e.g. multimedia streaming)

Network Connections (Wired, Wireless)

Protocols (e.g. TCP, UDP)

Mechanisms dealing with congestion:

Congestion control Congestion avoidance / Bandwidth estimation


Real-Time QoS Parameters

End-to-end Delay

Delay Variation

Delay variation is usually caused by the variable queuing and processing delays on routers during periods of increased traffic and sometimes by routing changes.

Delay variation is responsible for network jitter, which has unpleasant effects in a real-time application, as packets often reach the receiver later than required.

Packet loss

Packet loss is typically the result of excessive congestion on the network.

In a heterogeneous wired/wireless environment, apart from congestion, hand-offs and fading channels may result in packet drops.


Delay and Jitter Guidelines for VoIP

Delay Effect in perceived quality

Less than 150 ms Delay is not noticeable

150 - 250 ms Acceptable quality with slight speech impairments

Over 250 - 300 ms Unacceptable delay, conversation is inefficient

Delay Variation Effect in perceived quality

Less than 40 ms Jitter is not noticeable

40 - 75 ms Acceptable quality with minor impairments

Over 75 ms Unacceptable quality, too much jitter


User Datagram Protocol (UDP)

A real-time application has the option to run over TCP or UDP.

UDP is a fast, lightweight protocol without any transmission or

retransmission control.

However, UDP has certain limitations:

it does not incorporate any congestion control mechanism

the design principles of UDP do not anticipate fairness, thus, any applications running over UDP are not fair

The Internetworking functionality evolves towards punishing free-

transmitting protocols


Transmission Control Protocol (TCP)

The sliding window adjustments of TCP do not provide the regular flow

required by real-time applications when transmitting data.

Since standard TCP was designed for wired Internet, it does not perform

well in heterogeneous wired/wireless environments. More precisely, TCP

demonstrates some major shortfalls:

ineffective bandwidth utilization

unnecessary congestion-oriented responses to wireless link errors (e.g. fading channels) and operations (e.g. handoffs)

The effect of these awkward conditions is long and varying delays, which

damage the timely delivery of real-time data.


AIMD Congestion Control

TCP-style additive-increase/multiplicative decrease (AIMD) is inappropriate for streaming media:

TCP causes large, drastic rate changes

Win

do

w

Time

Slow start

Goal: Smooth rate adjustments


TCP-Friendly Protocols

TCP-Friendly are TCP compatible protocols, which satisfy two primary

objectives:

achieve smooth window adjustments by reducing the window decrease ratio during congestion, and

compete fairly with TCP flows by reducing the window increase factor according to a steady state TCP throughput equation

Three representative TCP-Friendly protocols, which are highly advisable

for real-time applications:

TCP-Friendly Rate Control (TFRC)

TCP-Real

TCP Westwood


Contents

Introduction


Real-time Performance MetricReal-time Performance Metric





Real-Time Performance Metric

Traditional performance metrics (e.g. throughput) do not effectively capture the bandwidth and delay characteristics of real-time traffic.

In this context, Real-Time Performance metric is proposed:

1packetssent #

packets received timely# ePerformanc TimeReal


Algorithm: Timely Received Packets

# For each packet received with sequence number i, determine # whether it is a timely received packet or a delayed packet

if threshold > 0 then

set packetTime[i] = currentTime

increase packetsReceived

if i = 0 then

increase timelyPackets

else

if packetTime[i] - PacketTime[i - 1] > threshold then

increase delayedPackets

end if

end if

end if

set timelyPackets = packetsReceived - delayedPackets


Contents

Introduction



Performance of MPEG-4 video delivery / VoIPPerformance of MPEG-4 video delivery / VoIP




MPEG Performance

0

10

20

30

40

50

60

70

80

90

100

1 10 20 40 80

Number of MPEG flows

Mb

ps

RenoVegasWestwood

Westwood+UDP

0,0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

1,0

1 10 20 40 80


RenoVegasWestwoodWestwood+UDP

System Goodput

Average Real-Time Performance

0,0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

1,0

1 10 20 40 80


RenoVegasWestwoodWestwood+UDP

Fairness Index


MPEG Performance vs. Buffer Size (1)

0

10

20

30

40

50

60

70

80

0 5 11 16 21 27 32 37 42 47 53 58

Time (sec)

Pac

kets

305080

0

10

20

30

40

50

60

70

80

0 5 11 16 21 27 32 38 43 48 53 59

Time (sec)

Pac

kets

3050

80

0

10

20

30

40

50

60

70

80

0 5 10 15 20 25 30 35 40 45 50 55

Time (sec)

Pac

kets

3050

80

TCP Reno

TCP Vegas

UDP


MPEG Performance vs. Buffer Size (2)

Queue Limit (20 Flows) 20 30 50 80

TCP Reno 3.0 5.4 8.8 16.1

TCP Vegas 5.5 7.6 7.7 7.7

UDP 16.9 27.2 46.6 75.7

Queue Limit (40 Flows) 20 30 50 80

TCP Reno 4.7 7.4 14.3 24.4

TCP Vegas 7.1 11.3 19.0 29.2

UDP 18.5 28.3 48.1 77.8


Simulation Topology for VoIP Evaluation


VoIP Performance

0

200

400

600

800

1000

1200

1400

1600

1800

2000

10 20 40 80 120

Number of VoIP flows

Kb

ps

Vegas

Westwood

Real

UDP

0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

1

10 20 40 80 120


Vegas

Westwood

Real

UDP

System Goodput


Delayed Pack.

0,00

0,02

0,04

0,06

0,08

0,10

0,12

0,14

0,16

0,18

0,20

10 20 40 80 120


Vegas

Westwood

Real

UDP


VoIP Traffic Friendliness

Goodput of 20 FTP flows


0

1

2

3

4

5

6

7

8

9

10

10 20 40 80 120


Mb

ps

Vegas

Westwood

Real

UDP

0

1

2

3

4

5

6

7

8

9

10

10 20 40 80 120


Mb

ps

Vegas

Westwood

Real

UDP


Contents

Introduction




Scalable Streaming Video Protocol (SSVP)Scalable Streaming Video Protocol (SSVP)



The need for End-to-end Congestion Control

Congestion control is mandatory and protocols which do not incorporate such mechanisms (i.e. UDP) have limited efficiency and potential.

We need sophisticated congestion control that interacts

efficiently with other flows on the Internet.

Routers play a relatively passive role: they merely indicate congestion through packet drops or ECN.

The end-systems perform the crucial role of responding appropriately to the congestion signals.


Where to implement congestion control?

Application-level congestion control is difficult and not part of most applications’ core needs.

Congestion control without reliability on top of TCP requires

several modifications considering the TCP semantics and its reliance on cumulative acknowledgments.

Implementing congestion control on top of UDP is more

appropriate, due its unreliable and out-of-order delivery.


The outcome…

A new transport protocol is needed, which would combine unreliable datagram delivery with built-in congestion control.

This protocol would act as an enabling technology: new and existing applications could use it to timely transmit data without destabilizing the Internet.


SSVP Design Principles

Scalable Streaming Video Protocol (SSVP) is a new transport protocol operating on top of UDP.

SSVP is intended to support a plethora of streaming applications, which are capable of adjusting their transmission rate based on congestion feedback.

The protocol incorporates end-to-end congestion control and does not rely on QoS functionality in routers, such as RED or ECN.

The objective is to provide efficient and smooth rate control while maintaining friendliness with corporate flows.


SSVP Packet Header


SSVP: Server and Receiver Interaction

SSVP acknowledges each datagram received by transmitting a control

packet.

Control packets:

do not trigger retransmissions are effectively used in order to determine bandwidth and RTT

estimates, and consequently properly negotiate and adjust the rate of the transmitted video stream.

The receiver uses packet drops or re-ordering as congestion indicator.

Consequently, congestion control is triggered, when:

a packet is received carrying a sequence number greater than the expected sequence number

the receiver does not acquire any packets within a timeout interval.


SSVP: Rate Adjustment (1)

The desired scalability can be attained through various

transcoding techniques, such as simulcast or layered adaptation.

The receiver detects the state of congestion and determines the

next transmission rate in terms of a pre-defined scale value:

if no congestion is detected, the scale value is increased by 1

in case of congestion, the scale value is decreased by 1

In order to explore the available bandwidth, transmission initiates

with the lower scale value and increases linearly.


SSVP: Rate Adjustment (2)

The receiver uses control packets to periodically send feedback of reception statistics to the sender.

Each control packet generated is updated with a scale value (through the field video scale) which signifies the proper transmission rate to the sender.

The linear scale adjustments are automatically translated to gentle fluctuations in the transmission rate resulting in a smooth and regular video flow.


Simulation Topology for SSVP Evaluation


Experimental Video Scale Assignment

Scale Value Avg. Bit Rate (Kbps)

4 340

3 256

2 170

1 86


SSVP vs. UDP (1)

0

1

2

3

4

5

6

7

8

9

10

0 10 20 30 40 50 60 70


Mb

ps

UDP

SSVP

0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

1

0 10 20 30 40 50 60 70


UDP

SSVP

MPEG-4 Goodput


Delayed Packets

0,00

0,05

0,10

0,15

0,20

0,25

0,30

0,35

0,40

0 10 20 30 40 50 60 70


UDP

SSVP


SSVP vs. UDP (2)

0,0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0 10 20 30 40 50 60 70


UDP

SSVP

0

5

10

15

20

25

30

35

40

45

50

0 10 20 30 40 50 60

Time (sec)

Pac

kets

UDPSSVP

Packet Loss Rate

Queue Length at Router R3

Fairness Index

0,0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

1,0

1 10 20 30 40 50 60

Number of MPEG flowsUDP

SSVP


SSVP Friendliness

0

1

2

3

4

5

6

7

8

9

10

0 10 20 30 40 50 60 70


Mb

ps

UDP

SSVP

0

1

2

3

4

5

6

7

8

9

10

0 10 20 30 40 50 60 70


Mb

ps

UDP

SSVP




Contents

Introduction





Real-time streaming with TCP over satellite linksReal-time streaming with TCP over satellite links


Characteristics of satellite links

Geostationary Earth Orbit (GEO) Satellite systems exhibit:

long latency (550ms) transmission errors or channel unavailability

Low Earth Orbit (LEO) Satellite systems exhibit:

relatively smaller delays (40 - 200ms) more variable delays

Most types of satellite links exhibit bandwidth asymmetry, since they comprise: a high-capacity forward space link, and a low-bandwidth reverse space/terrestrial path


TCP Issues over Satellite Links

TCP is dramatically affected by:

Long delays Large delay-bandwidth products Transmission errors

Long delays increase the duration of the Slow-Start phase:

the sender often allocates a small portion of the available network resources

the transmission of small amounts of data (e.g. web transfers) is dramatically affected, since the entire transfer may occur within the Slow-Start phase


Improving TCP-over-Satellite

Larger congestion window (window scale option)

Selective ACKs (SACK)

Fast Recovery can only recover one packet loss per RTT SACK allows multiple packet recovery per RTT

Delayed ACKs

effectively reduce back traffic the delay adjustment is critical (an improper adjustment may

increase transmission delay)


0,00

0,05

0,10

0,15

0,20

0,25

0,30

0 10 20 30 40 50


Reno

SACK

Westwood

Real

TCP-over-satellite Performance

0,0

0,5

1,0

1,5

2,0

2,5

3,0

3,5

4,0

4,5

5,0

1 10 20 30 40 50


Mb

ps

RenoSACKWestwoodReal

0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

1

1 10 20 30 40 50



System Goodput


Delayed Packets


TCP Performance vs. Error Rates (20 Flows)

0,0

0,5

1,0

1,5

2,0

2,5

3,0

3,5

4,0

4,5

5,0

0,000001 0,00001 0,0001 0,001 0,01

Bit Error Rate

Mb

ps


0,0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

1,0

0,000001 0,00001 0,0001 0,001 0,01

Bit Error Rate


System Goodput


Delayed Packets

0,00

0,05

0,10

0,15

0,20

0,25

0,30

0,35

0,40

0,45

0,50

0,000001 0,00001 0,0001 0,001 0,01

Bit Error Rate



Effect of Delayed ACKs (TCP SACK)

0,0

0,5

1,0

1,5

2,0

2,5

3,0

3,5

4,0

4,5

5,0

1 10 20 30 40 50


Mb

ps

No delack100ms delack200ms delack500ms delack

0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

1

1 10 20 30 40 50



System Goodput


Delayed Packets

0,00

0,05

0,10

0,15

0,20

0,25

0,30

0,35

0,40

0 10 20 30 40 50




Thank you!

Documents

On Transport Layer Mechanisms for Real-Time Application QoS 8 December 2005 Panagiotis Papadimitriou { [email protected] } ComNet Lab Demokritos University