On Transport Layer Mechanisms for Real-Time Application QoS

1
On Transport Layer Mechanisms for Real-Time
Application QoS
Panagiotis Papadimitriou ppapadim_at_ee.duth.gr
ComNet Lab Demokritos University of
Thrace Xanthi, GREECE

• 
  
• 8 December 2005

2
Contents

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

3
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

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

5
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
6
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

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

8
AIMD Congestion Control

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

TCP causes large, drastic rate changes
Slow start

• Goal Smooth rate adjustments

9
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

10
Contents

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

11
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

12
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 gt 0
then set packetTimei currentTime
increase packetsReceived if i 0 then
increase timelyPackets else if
packetTimei - PacketTimei - 1 gt threshold
then increase delayedPackets
end if end if end if set timelyPackets
packetsReceived - delayedPackets
13
Contents

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

14
MPEG Performance
System Goodput
Fairness Index
Average Real-Time Performance
15
MPEG Performance vs. Buffer Size (1)
16
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
17
Simulation Topology for VoIP Evaluation
18
VoIP Performance
19
VoIP Traffic Friendliness
Goodput of 20 FTP flows
Goodput of 60 FTP flows
20
Contents

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

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

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

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

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

25
SSVP Packet Header
26
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.

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

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

29
Simulation Topology for SSVP Evaluation
30
Experimental Video Scale Assignment
Scale Value Avg. Bit Rate (Kbps)
4 340
3 256
2 170
1 86
31
SSVP vs. UDP (1)
32
SSVP vs. UDP (2)
33
SSVP Friendliness
Goodput of 30 FTP flows
Goodput of 50 FTP flows
34
Contents

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

35
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

36
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

37
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)

38
TCP-over-satellite Performance
39
TCP Performance vs. Error Rates (20 Flows)
40
Effect of Delayed ACKs (TCP SACK)
41

• Thank you!