Quality of Service Management for Teleteaching Applications Using the MPEG-4/DMIF Gregor v. Bochmann and Zhen Yang University of Ottawa Presentation at the IDMS conference in Toulouse, October 1999 This work was funded by CITO and NortelNetworks 1 Three-level architecture: Application Entertainment Tele-training Home Shopping Distance Education Digital Library News Retrieval API Service Enabling Software Database Management QoS Negotiation Media Synchronization Distributed File Systems Authentication Accounting and Billing Base Software and Hardware LAN s Server Computers Hubs / Routers ATM Switches Workstations Wireless Base Stations 2 Page 1 1
QoS considerations within the overall system architecture QoS considerations concern performance properties influencing the quality of multimedia presentations (including type of guarantee: best effort, classes of service, deterministic guarantees), such as: Network: throughput, delay, jitter System response time (e.g. for Web servers) End-user wishes and requirements: sound quality, video quality, colour rendering, cost -- weight among different properties Client system: limitations due to screen size and precision, audio equipment, operating system s real-time response, available decoding software, etc. Server system (continuous media file server): number of users, overall throughput limitations, access delay and jitter Stored MM documents: encoding, possibly scalable (or several variants) -- including strongly reduced versions (e.g. video replaced by still images, drawings, voice replaced by text, etc.) 3 A target application: teleteaching Characterized by: Multimedia communication Very large number of receivers, only one sender Multicasting, possibly without restriction on number of receivers Different quality of service (QoS) requirements by different receivers quality of video (frame rate, size, etc.) quality of audio (e.g. telephone or CD quality) cost (depending on selected presentation quality) Sender should not negotiate quality parameters with each receiver individually Possibly access to multimedia databases 4 Page 2 2
Teleteaching: General assumptions Sender multicasts several different quality variants for each logical media channel (possibly using scalable encodings) A user manager contains information about the user s QoS preferences (user profiles) and may also be used for user authentification. The sender node may communicate with a local network QoS monitor which, in the case of best-effort networks, provides information about the transmission quality that is presently available. In the future, different classes of network services will be available. Receivers have different network access capabilities, e.g. low-speed or high-speed modems, wireless, etc. 5 Varying QoS requirements Different receivers may have different QoS requirements, depending on hardware/software resources available at the workstation/terminal user preferences (cost vs quality, relative importance of video vs voice, etc.) available bandwidth and loss rate for transmission to the particular user (consider low-speed modem, wireless connections, etc.) 6 Page 3 3
Demonstration prototype: Architecture see WORD document Sender Appl. Module Logical Logical QoS Manager StreamA StreamB User Interface Local Network QoS Monitor Session Management Transport Protocols Real-time Streams Network Control Messages Transport Protocols Transport Protocols Session Management Session Management User Interface Logical Logical QoS Agent StreamA StreamB Receiver Appl. Module Logical Logical StreamA StreamB QoS Agent Receiver Appl. Module User Interface User Profile Manager 7 Use of standard protocols, if possible Transport: IP, UDP IP multicasting: the prototype uses the MBone system Network performance monitoring: RTP/RTCP Session management knowledge about the participating users: RTCP channel management for the different multimedia streams: 'HOLYHU\Ã0XOWLPHGLDÃ,QWHJUDWLRQÃ)UDPHZRUNÃ'0,)Ãof MPEG-4 (with some small modification/extension) Media encoding: various standard voice and video coding schemes, plus extensions dealing with packet loss 8 Page 4 4
Scenario for a receiver entering a session Sender Appl. QoS Manager QoS Agent Receiver Appl. Start (port2) Give_QoS_Info (session_id, qos_list) New channel 2 Ask_QoS_Info (session_id, user_id) New receiver joining 2 session Give_QoS_Info (session_id, qos_list) Play (port1) Use channel 1 Ask_Add_QoS (session_id, user_id, 3 QoS violation qos) 4 Request inactive Stop (port1) Play (port2) channel 4 Use channel 2 Start (port4) Give_QoS_Info (session_id, qos_list) Stop (port2) Play (port4) Use channel 4 9 MPEG-4 MPEG-4 and the DMIF low data rate multiple media streams, e.g. one video stream for each moving object in a virtual environment variable shape of video surface (depending on object shape, not only rectangular) Delivery Multimedia Integration Framework (DMIF) hides delivery technology (e.g. from disk, over network) through the DMIF Application Interface (DAI) in case of network delivery:» session-level protocol (a control channel, identified by a URL + several data channels, allocated to different media streams)» management of network QoS» lower interface to the network: DMIF-Network Interface (DNI)» Version 2 (under development) deals with multicasting 10 Page 5 5
Scenario using DMIF Sender QoS Manager DMIF Network DMIF QoS Agent Receiver DA_ServiceAttach (URL,uuData) 1 Start(IP, Port1) OUT: ssid, response, uudata New channel 2 New receiver joining session DA_ServiceAttach 2 (URL,uuData) OUT: ssid, response, uudata Connect to ch 1 Monitor ch 1 DA_ChannelAdd OUT:chID,rsp,uuData DA_ChannelMonitor (chid,qosmode) Play(port1) 2 Use channel 1 Start(IP, port4) DA_UserCommand Callback(ssID, uudata) DA_ChannelAdd (ssid, dir, qosdescriptor, uudata) OUT: chid, resp, uudata Request inactive channel 4 DA_ChannelEvent (chid, qosreport) DA_UserCommand (ssid, uudata) DA_ChannelAddCallback (chid, dir, qosdescriptor, uudata) OUT: resp, uudata 4 3 QoS violation Stop(port1) Play(port2) Use channel 2 Stop(port1) Play(port4) DA_ChannelAdd OUT:chID,rsp,uuData Use channel 4 11 Extensions to DMIF For using DMIF in our context, we introduced the following extensions: Extended SyncState parameters (information about active channels) information about inactive channels in addition to network QoS parameters, include application-level parameters, such as frame rate, coding scheme, resolution, cost Receivers join channels explicitely DMIF assumes all receivers receive all channels; we want to multicast the streams only to those receivers that use them new Channel-Listen primitive Requests from receivers to sender for requesting the activation of another stream variant we use the DMIF User-Command primitive for this purpose 12 Page 6 6
User interface for setting a profile 13 Monitoring window showing different media variants 14 Page 7 7
Conclusions For distributed multimedia applications in a heterogeneous environment, with a large number of simultaneous receivers, one has to provide different quality and cost options for the receivers. Various appropriate coding schemes, including scalable hierarchical ones, exist or have been proposed. The MPEG-4/DMIF is an interesting session protocol, which can be adapted for various applications, including multi-quality multicasting of video conferences. 15 Ongoing research avenues Coding schemes for becoming more robust against packet losses Adaptive transmission rate control (as in TCP) for avoiding network congestion Experimenting with different policies at the sender: deciding which kinds of stream variants should be sent (with fixed or adaptive rate control) at the receiver: selecting the best available stream variant based on the high-level quality preferences of the user Experimenting in realistic Internet environments, including experimental differentiated services 16 Page 8 8
Future directions We plan to explore the following directions Distribution of QoS management from the sender towards certain nodes in the multicast tree for handling VERY large numbers of users for adapting media stream qualities at subnetwork boundaries, such as between backbone and wireless or telephone networks Studying the collective user behavior under different charging schemes, including special offers and/or bonuses for congestion avoidance Extending our work on session management to other types of applications, e.g. teleconference with multiple speakers, IP telephony, MPEG-4 applications including virtual worlds, etc. -- relationship with other protocols, e.g. SIP Use of programmable networks for realizing the above 17 Example configuration: Two video qualities sender a1 a3 r6 quality 1 receiver quality 2 receiver a2 quality 1 stream quality 2 stream r4 18 Page 9 9
Benefits: Different perspectives User s perspective Given user s benefit function: benefit (in $) as function of QoS obtained (this boils down to the question: what price is the user willing to pay? ) Optimize relative benefit: obtained benefit minus price to pay» based on tariff structure of networks and servers» also depending on adaptation possibilities of the application software and hardware Network perspective Optimize profit = income minus operating costs» This leads to the network tariff structure (based on assumptions about number of users and the user s benefit functions) price price User 1 QoS User 2 QoS 19 Page 10 1