1 / 41

On Transport Layer Mechanisms for Real-Time Application QoS

This article explores the state-of-the-art transport mechanisms for real-time applications, focusing on performance metrics, TCP and UDP protocols, and TCP-friendly protocols.

aseals
Download Presentation

On Transport Layer Mechanisms for Real-Time Application QoS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. On Transport Layer Mechanisms for Real-Time Application QoS Panagiotis Papadimitriou { ppapadim@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 ComNet Lab - 8 December 2005

  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 ComNet Lab - 8 December 2005

  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. ComNet Lab - 8 December 2005

  5. Delay and Jitter Guidelines for VoIP ComNet Lab - 8 December 2005

  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 punishingfree- transmitting protocols ComNet Lab - 8 December 2005

  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. ComNet Lab - 8 December 2005

  8. Window Time 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 ComNet Lab - 8 December 2005

  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 ComNet Lab - 8 December 2005

  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 ComNet Lab - 8 December 2005

  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: ComNet Lab - 8 December 2005

  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 > 0 then set packetTime[i] = currentTime increase packetsReceived if i = 0 then increasetimelyPackets else if packetTime[i] - PacketTime[i - 1] > threshold then increase delayedPackets end if end if end if set timelyPackets = packetsReceived - delayedPackets ComNet Lab - 8 December 2005

  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 ComNet Lab - 8 December 2005

  14. MPEG Performance System Goodput Fairness Index Average Real-Time Performance ComNet Lab - 8 December 2005

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

  16. MPEG Performance vs. Buffer Size (2) ComNet Lab - 8 December 2005

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

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

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

  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 ComNet Lab - 8 December 2005

  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. ComNet Lab - 8 December 2005

  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. ComNet Lab - 8 December 2005

  23. The outcome… • A new transport protocol is needed, which would combine unreliable datagram delivery with built-in congestioncontrol. • This protocol would act as an enabling technology: new and existing applications could use it to timely transmit data without destabilizing the Internet. ComNet Lab - 8 December 2005

  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. ComNet Lab - 8 December 2005

  25. SSVP Packet Header ComNet Lab - 8 December 2005

  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. ComNet Lab - 8 December 2005

  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. ComNet Lab - 8 December 2005

  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. ComNet Lab - 8 December 2005

  29. Simulation Topology for SSVP Evaluation ComNet Lab - 8 December 2005

  30. Experimental Video Scale Assignment ComNet Lab - 8 December 2005

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

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

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

  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 ComNet Lab - 8 December 2005

  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 ComNet Lab - 8 December 2005

  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 ComNet Lab - 8 December 2005

  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) ComNet Lab - 8 December 2005

  38. System Goodput Delayed Packets Average Real-Time Performance TCP-over-satellite Performance ComNet Lab - 8 December 2005

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

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

  41. Thank you! ComNet Lab - 8 December 2005

More Related