1. On Transport Layer Mechanisms for Real-Time Application QoS 8 December 2005 Panagiotis Papadimitriou { ppapadim@ee.duth.gr } ComNet Lab Demokritos University of Thrace Xanthi, GREECE

2. ComNet Lab - 8 December 2005 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. ComNet Lab - 8 December 2005 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. ComNet Lab - 8 December 2005 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. ComNet Lab - 8 December 2005 Delay and Jitter Guidelines for VoIP DelayEffect in perceived quality Less than 150 msDelay is not noticeable 150 - 250 msAcceptable quality with slight speech impairments Over 250 - 300 msUnacceptable delay, conversation is inefficient Delay VariationEffect in perceived quality Less than 40 msJitter is not noticeable 40 - 75 msAcceptable quality with minor impairments Over 75 msUnacceptable quality, too much jitter

6. ComNet Lab - 8 December 2005 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. ComNet Lab - 8 December 2005 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. ComNet Lab - 8 December 2005 AIMD Congestion Control TCP-style additive-increase/multiplicative decrease (AIMD) is inappropriate for streaming media: TCP causes large, drastic rate changes Window Time Slow start Goal: Smooth rate adjustments

9. ComNet Lab - 8 December 2005 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. ComNet Lab - 8 December 2005 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. ComNet Lab - 8 December 2005 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. ComNet Lab - 8 December 2005 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 set timelyPackets = packetsReceived - delayedPackets

13. ComNet Lab - 8 December 2005 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. ComNet Lab - 8 December 2005 MPEG Performance System Goodput Average Real-Time Performance Fairness Index

15. ComNet Lab - 8 December 2005 MPEG Performance vs. Buffer Size (1) TCP Reno TCP Vegas UDP

16. ComNet Lab - 8 December 2005 MPEG Performance vs. Buffer Size (2) Queue Limit (20 Flows)20305080 TCP Reno3.03.05.48.816.1 TCP Vegas5.55.57.67.67.7 UDP16.927.246.675.7 Queue Limit (40 Flows)20305080 TCP Reno4.77.414.324.4 TCP Vegas7.111.319.029.2 UDP18.528.348.177.8

17. ComNet Lab - 8 December 2005 Simulation Topology for VoIP Evaluation

18. ComNet Lab - 8 December 2005 VoIP Performance System Goodput Average Real-Time Performance Delayed Pack.

19. ComNet Lab - 8 December 2005 VoIP Traffic Friendliness Goodput of 20 FTP flows Goodput of 60 FTP flows

20. ComNet Lab - 8 December 2005 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. ComNet Lab - 8 December 2005 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. ComNet Lab - 8 December 2005 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. ComNet Lab - 8 December 2005 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. ComNet Lab - 8 December 2005 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. ComNet Lab - 8 December 2005 SSVP Packet Header

26. ComNet Lab - 8 December 2005 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. ComNet Lab - 8 December 2005 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. ComNet Lab - 8 December 2005 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. ComNet Lab - 8 December 2005 Simulation Topology for SSVP Evaluation

30. ComNet Lab - 8 December 2005 Experimental Video Scale Assignment Scale ValueAvg. Bit Rate (Kbps) 4340 3256 2170 186

31. ComNet Lab - 8 December 2005 SSVP vs. UDP (1) MPEG-4 Goodput Average Real-Time Performance Delayed Packets

32. ComNet Lab - 8 December 2005 SSVP vs. UDP (2) Packet Loss Rate Queue Length at Router R3 Fairness Index

33. ComNet Lab - 8 December 2005 SSVP Friendliness Goodput of 30 FTP flows Goodput of 50 FTP flows

34. ComNet Lab - 8 December 2005 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. ComNet Lab - 8 December 2005 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. ComNet Lab - 8 December 2005 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. ComNet Lab - 8 December 2005 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. ComNet Lab - 8 December 2005 TCP-over-satellite Performance System Goodput Average Real-Time Performance Delayed Packets

39. ComNet Lab - 8 December 2005 TCP Performance vs. Error Rates (20 Flows) System Goodput Average Real-Time Performance Delayed Packets

40. ComNet Lab - 8 December 2005 Effect of Delayed ACKs (TCP SACK) System Goodput Average Real-Time Performance Delayed Packets

41. ComNet Lab - 8 December 2005 Thank you!