1 / 22

FEC-Integrated Network Traffic Shaping Using the NIProxy

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 {maarten.wijnants,wim.lamotte}@uhasselt.be. Outline. Background and Motivation

devlin
Download Presentation

FEC-Integrated Network Traffic Shaping Using the NIProxy

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. FEC-Integrated Network Traffic Shaping Using the NIProxy Maarten Wijnants, Wim LamotteHasselt University – Expertise Centre for Digital Media (EDM) Wetenschapspark 2, BE-3590 Diepenbeek, Belgium {maarten.wijnants,wim.lamotte}@uhasselt.be

  2. Outline • Background and Motivation • Error Correction Techniques • Network Intelligence Proxy • Objectives & Methodology • FEC Integration in NIProxy • Evaluation • Experiment Description • Experimental Results & Findings • Conclusions EMERGING2009

  3. 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! EMERGING2009

  4. 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 EMERGING2009

  5. 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) EMERGING2009

  6. 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! EMERGING2009

  7. 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 EMERGING2009

  8. Network Intelligence ProxyMethodology • 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 EMERGING2009

  9. Network Intelligence ProxyNetwork 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 EMERGING2009

  10. Network Intelligence ProxyNetwork 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 EMERGING2009

  11. 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 EMERGING2009

  12. 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 EMERGING2009

  13. 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 EMERGING2009

  14. 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) EMERGING2009

  15. EvaluationExperimental Setup High capacity; Error-free Resource constrained; Error-prone FEC support advantageously influences NIProxy’s user QoE optimization capabilities? Video streaming case study EMERGING2009

  16. EvaluationExperiment 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 EMERGING2009

  17. EvaluationExperiment 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 EMERGING2009

  18. EvaluationExperiment Description FEC protected Video Session VS2 Split access bandwidth equitably Static JSCC(90%-10%) XOR disabledn = 3; n = 6 Unprotected Video Session VS1 SD_BW_ALLOC_CONSTRAINED Stream hierarchy which steered the shaping of the network traffic EMERGING2009

  19. EvaluationExperimental Results Access BW gradually more constrainedIncreasing flow BW reductions required All streams at max quality FEC coding disabled VS2 transcoded to lower quality Execution 1: Error-free environment EMERGING2009

  20. EvaluationExperimental Results Video playback at destination no longer perfect!  Residual vs original packet loss VS2 = 92 vs 210 Playback VS2 less distorted!  Execution 2: 10% packet loss EMERGING2009

  21. EvaluationExperimental 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) EMERGING2009

  22. 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 EMERGING2009

More Related