Managing Client Bandwidth in the Presence of Both Real-Time and non Real-Time Network Traffic Maarten Wijnants Wim Lamotte

08/01/2008COMSWARE20082 Outline Introduction –Need for Bandwidth Management –Real-time vs non real-time network traffic NIProxy –System Overview –Objectives & Mode of Operation Client Bandwidth Management Evaluation –Experimental Setup & Results Conclusions & Future Work

08/01/2008COMSWARE20083 Introduction Increasing incorporation of multimedia content into networked applications –E.g. evolution textual chat to more immersive forms of user communication –Will normally provide user with better experience –However: considerable bandwidth is required to exchange multimedia data over a network Bandwidth consumption of networked applications has risen substantially –Clients do not always dispose of sufficient downstream bandwidth

08/01/2008COMSWARE20084 Introduction Need for client bandwidth management –Should occur both intelligently and effectively –Goal = maximize user experience/satisfaction Possible approaches –Implement unique solution for each application –Develop reusable solution Economically more favorable “Communication middleware” NIProxy: network intermediary supporting client bandwidth management –Example of communication middleware

08/01/2008COMSWARE20085 Introduction Real-time network traffic –Content/media with real-time characteristics –Very sensitive to delay –Needs to be delivered to destination “in time” –Typically continuous, long-lived streams that are transmitted using e.g. UDP Non real-time network traffic –E.g. file or P2P data –Less stringent constraints on its delivery time –Requires reliable and error-free delivery (TCP) –Often bursty and relatively short-lived

NIProxy The NIProxy –Network intermediary (a “proxy server”) –Objective = enhance the experience and satisfaction of users of networked applications Quality of Experience (QoE) –Approach = introduce additional awareness or context in the transportation network –Abbreviation for Network Intelligence Proxy 08/01/2008COMSWARE20086

NIProxy NIProxy is network- and application aware –Network awareness: knowledge of the current state of the transportation network Acquired through active network probing Network-related measurements (e.g. current throughput, latency, packet loss rate, …) –Application awareness: knowledge of the networked application(s) the client is running Provided by client software –Facilitated by reusable auxiliary library called NILayer Depends on application’s requirements and its type –Example: relative stream importance 08/01/2008COMSWARE20087

NIProxy NIProxy performs QoE-optimization through –Automatic and dynamic client downstream bandwidth management –Multimedia service provisioning –Both can exploit NIProxy’s dual awareness Supported QoE-improving mechanisms are complementary & interoperable 08/01/2008COMSWARE20088

Client Bandwidth Management NIProxy manages client bandwidth by organizing network flows in a stream hierarchy –Tree-like structure –Leaf nodes always correspond to an actual network flow –Internal nodes implement a certain bandwidth distribution strategy, e.g. Mutex Weight Percentage 08/01/2008COMSWARE20089

Client Bandwidth Management Real-time network traffic –Stringent reception delay constraints –Only limited operations are possible E.g. no mid-stream buffering or reduced-rate transmission Management by NIProxy through discrete stream hierarchy leaf nodes –Sets the flow's bandwidth consumption to a discrete number of values –Simplest approach: turn network stream on/off –More complex: e.g. scalable network streams 08/01/2008COMSWARE200810

Client Bandwidth Management Non real-time network traffic –Less stringent reception delay constraints –Bit more management latitude Management by NIProxy through continuous stream hierarchy leaf nodes –Capable of setting a flow's transmission rate to a continuous range of values –Operation resembles that of leaky bucket: Local buffering of content transported by flow Rate-controlled transmission of buffered data to client 08/01/2008COMSWARE200811

Client Bandwidth Management Responsibility for constructing and maintaining stream hierarchy lies with client –Determine suitable stream hierarchy structure Provides NIProxy with application awareness –Adequately incorporate individual network flows Is facilitated by availability of –NILayer support library –NIProxy new/dead stream notification system 08/01/2008COMSWARE200812

Client Bandwidth Management Once stream hierarchy has been constructed, managing client downstream bandwidth = assigning correct amount of bandwidth to hierarchy root node –Internal nodes apportion bandwidth according to their bandwidth distribution technique –Discrete leaf nodes switch to the highest possible discrete bandwidth consumption level –Continuous leaf nodes adjust their tx rate Process is repeated periodically 08/01/2008COMSWARE200813

Implementation At which granularity should the NIProxy manage non real-time network traffic? –Fine-grained: incorporate each individual non real-time content object in stream hierarchy +Allows high & subtle level of control -Frequent updates of stream hierarchy necessary -Calculating client's bandwidth distribution consumes more time due to the increased stream hierarchy size –Coarse: provide support at the level of non real-time network flows Treat all non real-time data transferred over same flow identically 08/01/2008COMSWARE200814

Evaluation: Experimental Setup Networked application allowing user to set up real-time and non real-time network streams with remote hosts –Real-time traffic: video streaming Most demanding in terms of bandwidth Transmitted using RTP –Non real-time traffic: P2P file sharing Transmitted using TCP File sources transmit files sequentially in order of file request reception 08/01/2008COMSWARE200815

Evaluation: Experimental Results Validate if NIProxy is capable of managing client bandwidth in presence of both real- time and non real-time network traffic Approach –Real-time video connection between local client and two remote hosts H1 and H2 –Non real-time communication channel between local client and H1 as well as another remote host representing a dedicated file server (FS) geom.3ds: bytes; requested from FS img.png: bytes; requested from host H1 08/01/2008COMSWARE200816

Evaluation: Experimental Results Additional constraints and requirements –Significance video stream H1 > H2 –Priority non real-time connection FS > H1 –Non real-time communication should receive “fair” amount of the total downstream bandwidth available to the client (i.e. at least 30 percent) Allows comprehensive demonstration of the capabilities of NIProxy's bandwidth distribution mechanism 08/01/2008COMSWARE200817

Evaluation: Experimental Results Experiment was repeated three times –Without including NIProxy –With NIProxy (no video transcoding service) –With NIProxy (with video transcoding service) Video transcoding service allows NIProxy to reduce bandwidth requirements of video flows Experiment objectives –Investigate MM experience provided to client –Introduction of NIProxy improves user’s QoE? 08/01/2008COMSWARE200818

Evaluation: Experimental Results Without including NIProxy Simultaneous reception of real-time & non real- time traffic yielded issues –Wrongful penalization of non real-time traffic In disaccord with our “fair share” requirement –Video suffered from contention from non real- time traffic Deteriorated playback 08/01/2008COMSWARE200819

Evaluation: Experimental Results With NIProxy (no transcoding) Stream hierarchy constructed according to specified constraints Issues did not occur –Use percentage node guarantees non real-time traffic receives its bw share Faster file reception –Unaffected video reception Non real-time rate-control 08/01/2008COMSWARE200820

Evaluation: Experimental Results With NIProxy (and transcoding) Additional advantage: allows video traffic to more fully consume its bandwidth percentage –H2 TV when file traffic is initiated Has lower bandwidth requirements than H2 OV Forwarding it does not deny file transfer its fair bw share 08/01/2008COMSWARE200821

Evaluation: Experimental Results Principal findings –Client bandwidth was distributed correctly over real-time and non real-time network traffic –Allowed fulfillment of postulated requirements with minimal effort No substantial modifications to client software  Incorporation of NIProxy in experiment had positive influence on user's QoE Experiment also illustrates added value of allowing interoperation between NIProxy’s two QoE-increasing mechanisms 08/01/2008COMSWARE200822

Conclusions Networked applications are increasingly exploiting multimedia content –Client bw management gains in importance NIProxy: network intermediary aiming to improve user QoE –Through incorporating awareness in network –Client bw management & MM service provision NIProxy is capable of managing client downstream bw in presence of real-time as well as non real-time network traffic 08/01/2008COMSWARE200823

Future Work Extend NIProxy’s awareness with knowledge of client terminal and the end- user's preferences Investigate impact of employing NIProxy to manage client downstream bandwidth in a more realistic networked application –In-house developed NVE application Supports real-time voice and video chat Uses non real-time network communication to exchange different types of geometry information (IBR data, 3D models, textures, …) 08/01/2008COMSWARE200824

Thank you for your attention! Any questions?