FEC-Integrated Network Traffic Shaping Using the NIProxy Maarten Wijnants, Wim Lamotte Hasselt University – Expertise Centre for Digital Media (EDM) Wetenschapspark 2, BE-3590 Diepenbeek, Belgium

Outline Background and Motivation –Error Correction Techniques Network Intelligence Proxy –Objectives & Methodology FEC Integration in NIProxy Evaluation –Experiment Description –Experimental Results & Findings Conclusions 15/10/2009EMERGING20092

Background and Motivation Exchanging data over computer networks can lead to corruption –Data becomes (partly) unusable for receiver Data corruption can be caused by –The loss of entire packets E.g. insufficiently capacitated network infrastructure –The introduction of bit errors E.g. signal interference and noise on the channel Irrespective of its cause, data corruption is likely to degrade user experience –Effort should be made to minimize it! 15/10/2009EMERGING20093

Error Correction Techniques 2 data corruption countermeasure categories –Retransmission-based techniques : Receiver requests source to retransmit missing or corrupted data –Forward Error Correction (FEC) : Sender supplements source data with redundant info which allows receiver to repair, to a certain extent, errors introduced during transmission FEC schemes enable lost or damaged data recovery without incurring RTT overhead introduced in retransmission-based solutions 15/10/2009EMERGING20094

Error Correction Techniques Example FEC scheme: XOR-Based Parity Coding –Input = Group of n media packets –Output = Single parity packet Constructed by applying the XOR operator on the bits stored at identical locations in the n input packets –At decoding side, parity packet can be used to recover a singly lost/corrupted packet By XOR-ing the (n - 1) correctly received media packets with the (also perfectly received) parity pack –Important advantage: Run-time adaptability: Trade off protection for BW (by changing n) 15/10/2009EMERGING20095

Error Correction Techniques Retransmission- and FEC-based schemes share a common disadvantage –Both introduce overhead in terms of the amount of data that needs to be transmitted I.e. the BW requirements of data flows are raised The surprising scenario might occur where the addition of error protection yields an increased instead of a decreased error rate Deliberate decision making regarding the amount of protection to add to network traffic is advocated! 15/10/2009EMERGING20096

Network Intelligence Proxy Network intermediary (a “proxy”) –Can be incorporated in existing IP networks Goal = Optimize QoE of users of distributed applications Approach = Gather context and improve MM handling capabilities of transportation network to enable user QoE optimization –Network traffic shaping –Multimedia service provisioning NOT transparent 15/10/2009EMERGING20097

Network Intelligence Proxy Methodology NIProxy introduces “intelligence” in the networking infrastructure –2 distinct sources of contextual info are queried Source 1: Transportation network –Contextual knowledge = Quantitative network-related measurements and statistics –Obtained through active network probing & monitoring Source 2: Distributed application –Contextual knowledge = Any application-related knowledge that is deemed relevant –Needs to be provided by the application software 15/10/2009EMERGING20098

Network Intelligence Proxy Network Traffic Shaping Orchestrate bandwidth consumption by arranging flows in a stream hierarchy –Tree-like structure; expresses flow relationship –Internal nodes implement bandwidth distribution strategy Mutex : Available bandwidth BW allotted to child with largest still satisfiable bandwidth requirement Percentage : Each child i is granted its corresponding percentage value of the distributable bandwidth BW, i.e. –Leaf nodes correspond with actual flows Discrete leaf : Switch BW usage of associated flow between discrete number of levels 15/10/2009EMERGING20099

Network Intelligence Proxy Network Traffic Shaping Sibling dependencies framework –Enables dependencies to be enforced between sibling nodes in the stream hierarchy –Currently only 1 type of dependency defined, namely SD_BW_ALLOC_CONSTRAINED Set of supported sibling dependency types readily extensible –SD_BW_ALLOC_CONSTRAINED dependency between sibling nodes A and B specifies that B is allowed to consume bandwidth if and only if A’s bandwidth consumption is non-zero Node A can “borrow” bandwidth assigned to B 15/10/2009EMERGING200910

Network Intelligence Proxy Multimedia Service Provision NIProxy acts as service provision platform –In-network execution of (context-aware) services on transported data Implemented using a plug-in based design –Each service corresponds to a NIProxy plug-in Service cooperation through chaining NTS and MM service provision integrated in an interoperable manner! –Services can query/influence the bandwidth distribution strategy devised for clients –Unlocks extra QoE optimization possibilities 15/10/2009EMERGING200911

FEC Integration in NIProxy Given its negative impact on user experience, techniques to counter lost or damaged data are meaningful extensions of the NIProxy’s feature list Adaptive XOR-Based Parity coding implemented as NIProxy service Integrated approach with NIProxy NTS –FEC-generated network traffic might consume significant amounts of bandwidth Should be reckoned with by NIProxy’s NTS mechanism Necessitates FEC traffic inclusion in stream hierarchy 15/10/2009EMERGING200912

FEC Integration in NIProxy FEC incorporation in stream hierarchy –Redundant FEC parity data is represented as discrete stream hierarchy leaf node Defines a discrete bandwidth consumption level for each supported input packet grouping size –FEC data also needs to be adequately related to the media stream it protects (JSCC) Deliberately amortize BW that has been reserved for FEC- protected traffic among the media data and its FEC overhead In this paper: By using a Percentage node –Adjusting the percentage values assigned to both nodes allows the JSCC process to be controlled –SD_BW_ALLOC_CONSTRAINED dependency between the nodes representing the media and its FEC protection FEC can consume BW if and only if associated media flow is enabled 15/10/2009EMERGING200913

FEC Integration in NIProxy Operation of the NIProxy FEC service –Performs 2 initialization tasks on discovery of network stream eligible for FEC protection: Instantiate a XOR-based parity encoder Inform NTS process of possibility to FEC protect the stream and the thereby associated BW requirements –Main processing loop: Service exploits its interface with NTS to determine discrete level to which the FEC data for the media flow that is being processed is currently set FEC encoder is switched to the input grouping size that is associated with this level Packet is fed encoder (possibly producing parity packet) 15/10/2009EMERGING200914

Evaluation Experimental Setup FEC support advantageously influences NIProxy’s user QoE optimization capabilities? Video streaming case study 15/10/2009EMERGING High capacity; Error-freeResource constrained; Error-prone

Evaluation Experiment Description MM server maintained 2 simultaneous RTP video sessions with client: VS1 and VS2 –Video data emitted in unprotected form –NIProxy had its FEC service loaded Parity coding per 3 or per 6 input packets –Only video session VS2 was marked as being eligible for receiving FEC protection –Identical video fragment streamed over both sessions to allow meaningful comparison –NIProxy video transcoding service also loaded To address bandwidth shortage on the access network 15/10/2009EMERGING200916

Evaluation Experiment Description Experiment was executed twice –Once without and once with the netem component introducing packet loss on last mile –Access network throughput artificially modified at predefined points in time (5 times in total) Investigate effect on the way the NIProxy shaped the network traffic destined for the receiving client –All other conditions remained constant Bandwidth modifications conceptually divided the experiment into 6 discrete intervals 15/10/2009EMERGING200917

Evaluation Experiment Description Stream hierarchy which steered the shaping of the network traffic 15/10/2009EMERGING Unprotected Video Session VS1 FEC protected Video Session VS2 SD_BW_ALLOC_ CONSTRAINED Static JSCC (90%-10%) XOR disabled n = 3; n = 6 Split access bandwidth equitably

Evaluation Experimental Results Execution 1: Error-free environment 15/10/2009EMERGING All streams at max quality Access BW gradually more constrained Increasing flow BW reductions required VS2 transcoded to lower quality FEC coding disabled

Evaluation Experimental Results Execution 2: 10% packet loss 15/10/2009EMERGING Residual vs original packet loss VS2 = 92 vs 210 Video playback at destination no longer perfect!  Playback VS2 less distorted! 

Evaluation Experimental Results Findings and observations –Capacity of client’s access connection respected –Delineated BW distribution strategy successfully enforced Access bandwidth shared equitably among video sessions –Example of potential of supporting interoperation between NIProxy services and bandwidth brokering E.g. JSCC process steered entirely by NIProxy’s NTS –JSCC might require quality of MM data to be reduced to accommodate its FEC protection Therefore quality VS2 sometimes lower than VS1 FEC overhead however enables packet loss recovery –Playback VS2 smoother and less perceptually degraded –Lower quality yet less distorted = More enjoyable viewing experience than high-quality distorted video (subjective) 15/10/2009EMERGING200921

Conclusions MM data might arrive in corrupted form during its propagation through error-prone networks –Typical outcome = Deteriorated media presentation –Likely source for user frustration FEC schemes possess the ability to alleviate detrimental effects of data corruption –Enable receivers to repair compromised data FEC incorporated in NIProxy (XOR parity code) –FEC operations directed by NTS  Ensure XOR BW justified –Evaluated using video streaming case study –Results corroborate that FEC coding is valuable addition to NIProxy’s toolset to improve user QoE 15/10/2009EMERGING200922