QoS Requirements of Multimedia Applications

1. QoS Requirements of Multimedia Applications Brett Berliner Brian Clark Albert Hartono

2. Introduction • What does QoS mean? • Quality of Service • probability of the network/protocol meeting a given traffic contract. • Who negotiates this contract? • SLA (Service Level Agreement) • Usually done by prioritizing traffic • Sender and receiver • Mutual agreement • Improves reliability of contract by having both ends agree • Like with any contract negotiation is the key

3. Introduction Con’t • Generally not used for most traffic in internet • Usually things are not dependant on time domain • Web browsing, e-mail, ftp, etc. • TCP takes care of this for us • Mainly used for multimedia applications • Time is of the essence • Video, voice, games, etc. • Always a trade-off • Higher QoS (higher quality) -> More resources • Users of SLA must be fair and honest • Five basic parameters

4. Dropped Packets • A router must drop an incoming packet because buffer is full • No perfect solution to this problem • Some, none, or all might get dropped • Impossible to determine in advance • How to recover? • Receiver must request packets to be sent again • Causes severe delay • Sometimes not worth it to request packet again

5. Delay • Queuing • Time spent waiting in a queue at a router • Depends on congestion in the network • Usually in milliseconds • Processing Delay (usually caused by software) • At different layers, data must be processed • Usually in microseconds • Propagation Delay • Time for data to travel from A->B • Depends on distance, usually in milliseconds • Transmission Delay • Depends on bandwidth and length of message, usually in microseconds

6. Jitter • A lack of synchronization • Caused by different delays in packets • Result of packets taking different routes • Directly related to congestion • Extreme jitter can lead to out-of-order delivery • Packets need to be re-ordered at receiver • Sometimes this is impossible due to time constraints

7. Error • Packets do not always arrive in the exact state they were sent out in • Can be misdirected (sent to wrong destination) • Can get combined together by accident • Can have bit(s) flipped. • Receiver must request information to be sent again • Many times this is not practical for multimedia applications

8. Bandwidth • Amount of data that can be sent over a connection in a given amount of time • Commonly measured in bits/second • kbps or mbps instead • Sometimes a given connection is simply physically unable to fulfill a SLA • Imagine trying to stream HDTV quality video over a 14.4 kbps modem

9. What Happens When QoS Fails? • VoIP Example: • Delays followed by effect • < 100 – 150 ms: Delay is not detectable by humans • 150 – 250 ms: Acceptable quality, but delay and hesitation is noticeable • > 250 – 300 ms: Unacceptable. Normal conversation is impossible • Jitter followed by effect • < 40 ms: Jitter is not detectable • 40-75 ms: Good quality, but occasional jumble is noticeable • > 75 ms: Unacceptable. Too much jumble to carry a conversation

10. What Happens When QoS Fails? • Video Example • Out of sync image is a result of motion prediction. Result of loss of a P or B frame • Missing image parts result of a missing I frame

11. Summary of QoS Requirements For Specific Applications

12. Who’s Responsibility Is It? • Routers don’t know typically know what the data is • Thus, it requires a lot of overhead to allow the routers to interpret the data • The encoding and decoding of the data in the sender and the receiver(s) makes them a prime target • This is where most of the focus of ensuring that QoS requirements are met lies

13. Basic Types of QoS Technologies • Congestion/Traffic Control • Examples: RED, FRED, Droptail • Resource Management • Examples: IntServ, DiffServ • Queuing/Buffering • Priority Queuing, FRTS

14. Congestion Control Methods • RED/FRED • Droptail • Bucketing • QoS/BGP

15. Congestion Control Methods (cont.) • RED, FRED and Droptail Methods • Already discussed extensively in class • Methods to improve congestion, but like all methods, have their own drawbacks and benefits • Important to note that these methods only help improve QoS on a very high level. They improve congestion and traffic, which helps the entire internet, not just QoS issues.

16. Congestion Control Methods (cont.) • QoS / BGP (QoS Policy Propagation via Border Gateway Protocol) • BGP is the core routing protocol of the internet • Instead of using BGP solely to determine where to send the packets, build on top of BGP to classify the type of packets being sent • Allows other methods, like queuing or scheduling, to be used in conjunction to ensure QoS requirements are met

17. Resource Management Methods • IntServ (Integrated Services) • A fine grained QoS system • Individual applications must make indvidual reservations of resources • By making reservations, the application is guaranteed a certain level of service – from “best effort” to “100% guarantee”, and everything in between • Uses RSVP (Resource ReSerVation Protocol) to help determine what resources to allocate where.

18. Resource Management Methods (cont.) • DiffServ (Differentiated Services) • Much more coarse QoS system • Reservations are done in bulk, usually from a single source (such as a university or a single ISP) • Policing of data is done completely at DiffServ clouds (individual systems of routers) • Data with highest priority is given highest priority, within clouds only

19. Resource Management Methods (cont.) • Weaknesses of these methods: • IntServ • Similar to FRED, lots of data must be stored. Thus, hard to scale for the entire internet • DiffServ • Not a good system for most links. • Since the traffic comes in very large chunks (e.g., all traffic from OSU as well as all from Otterbein), there is likely to be relatively steady traffic. • If packets need to be dropped, more bandwidth is needed to fix the problem in most cases.

20. Queuing/Buffering Methods • FRTS (Frame Relay Traffic Shaping) • Excess traffic is delayed using a buffer or a queue • Idea is to shape the flow’s traffic, usually when the data rate of the source is higher than expected. • Works very well with a large queue or a small scale. If the queue is too small, or FRTS is run on a large scale (e.g., the whole internet), a queue management algorithm would be necessary.

21. Queuing/Buffering Methods (cont.) • CSFQ (Core Stateless Fair Queuing) • First step – edge nodes estimate the incoming rate of packets being sent, then uses that as a label for each of that flow’s packet • Next – all nodes (including edge) repeatedly estimate the fair rate from the outgoing link. Upon arrival, the probability the packet will be forwarded is calculated, based on the previously calculated probability, as well as the previous label. • When that packet is forwarded, it is sent with that probability, and the label is replaced with the smaller value between its previous value and the fair rate.

22. Queuing/Buffering Methods (cont.) • Advantages of CSFQ • Per flow management is performed, allowing each flow to get a fair rate • Stateless (less information stored, the better) • Disadvantages of CSFQ • Not a lot of room for allowing prioritization • Fair amount of calculation is necessary, and may be futile calculation

23. Queuing/Buffering Methods (cont.) • Priority Queuing • Multiple queues in implementation, each representing a level of priority (high, low, and a differing number in between) • Each queue gets only packets matching its priority level • Can change calculation equation on the fly

24. Queuing/Buffering Methods (cont.) • Advantages of Priority Queuing • Simple implementation • Very flexible • Disadvantages of Priority Queuing • Starvation is still possible • If equation remains stagnant, traffic could be lost in the queues

25. Queuing/Buffering Methods (cont.) • Weighted Fair Queuing • An implementation of Priority Queuing • Classifies all traffic through a series of qualifications to get the traffic in the best possible queues • Examples – interactive traffic goes before non-interactive, low bandwidth sessions go before high bandwidth sessions

26. Combing technologies • Right now, to ensure QoS, there are no ‘magic bullets’ • Each technology type has many methods for a reason • The way to effectively ensure QoS requirements best is to combine methods effectively • As a result, we see certain technologies that we cannot implement fully because of the inability to meet the necessary QoS requirements

27. Telesurgery • Robotic and computer-aided surgery across a distant location • Time-critical (delay-oriented) application • Data to send: • surgical movements • real-time medical images • voice and video signal

28. Telesurgery (cont.) • QoS requirements: • reliability of the network line • low end-to-end delay • low data error rate • data transfer from sources with various data rates • The acceptable limit of delay requirement: 330 ms

29. Telesurgery (cont.) • The use of the Internet for telesurgery is not possible • ATM and SDH/SONET (optical network) meet the network requirements of telesurgery.

30. Telesurgery (cont.) • On September 7th, 2002, the first human transoceanic (New York - Strasbourg, France) operation was successfully performed

31. Telesurgery (cont.) • High-speed optical-fiber network • Dedicated connection-oriented ATM transport • Reserved bandwidth of 10 Mbps • Measured mean-time of delays: 155 ms • ATM round trip delay: 78-80 ms • Video coding and decoding: 70 ms • Rate adaptation and Ethernet-to-ATM packet conversion: ~ 5 ms • No packet loss was detected

32. Remote Visualization • Interactive viewing of 3-D scientific data sets over networks • Gigabyte size range of data sets • Interactivity → tight delay requirement

33. Remote Visualization (cont.) • QoS requirements: • very high network bandwidth • low latency • constant jitter • The use of Internet for remote visualization is not feasible

34. Remote Visualization (cont.) • RealityGrid implements tools for computational steering in the Open Grid Services Architecture (OGSA)

35. Remote Visualization (cont.) • High bandwidth links → at least 700 Mbps • Compressed video sent to remote observers → 100 - 200 Mbps (with low latency and constant jitter) • These QoS requirements • increase linearly with #remote observers • doubled again if remote stereoscopic rendering is employed

36. Tele-Immersion • Enable individuals in different locations to interact with each other in a shared, computer-generated environment as if they were in the same physical room → Virtual Reality • The same QoS requirements as those of remote visualization

37. Conclusions • Some benefits of QoS: • Control over which resources are being used • Ensure time-critical and mission-critical applications have their required resources • More efficient use of existing network resources, rather than the need for expansion or upgrades • Foundation for a fully-integrated multimedia network needed in the near future • QoS of scientific-computation creates technical challenges for designing the next generation of network • The challenge of insuring QoS requirements is a large part of what drives today’s internet