: SN-based ross-layer Multi-stream Management Protool for 3 Teleimmersion hsan refin Raoul Rivas Rehana Tabassum Klara Nahrstedt University of Illinois at Urbana-hampaign, Urbana, IL {marefin2, trivas, tabassu2, klara}@illinois.edu bstrat Video onferening appliations pose fundamentally different servie requirements than traditional data traffi on the Internet. Strong real-time interativity is very important among partiipants unlike video streaming in Vo appliations. Requirements are even more stringent in multi-stream and multisite teleimmersive appliations due to strong dependenies aross geographially distributed streams. In this paper, we propose, a ross-layer session-network ontrol protool for multi-stream multi-site 3 teleimmersion (3TI) that improves interativity, resoure utilization and salability. deouples appliation layer data and ontrol plane funtionalities, and partially offloads the data plane funtionalities to network layer swithes. To ontrol network layer swithes during the session run-time, leverages support from Software efined ing (e.g., Openlow). Through extensive evaluation with multi-stream 3 teleimmersion among four distributed sites and PlanetLab-based larger 3TI setup, we show that improves 3TI interativity and resoure usage at the data plane. urthermore, keeps data plane robust against host failures and frequent route updates. I. INTROUTION We have seen a surge of interest in telepresene video ollaborative tehnologies over the past few years. Though the initial fous was on video onferening appliation [9][27], emerging is the 3 teleimmersion (3TI) tehnology that expands the horizon by supporting full-body interation of physial ativities in virtual environments. ppliations have been found in rehabilitation, ollaborative daning, and online gaming (e.g., [7], [39]) in addition to video onferening [9]. 3TI onsists of a real-time orrelated multi-stream environment, where distributed partiipants interat with eah other in a shared virtual spae by fusing streams from multiple 3 ameras, mirophones and other sensors. espite great potential, today s multi-stream 3TI still faes signifiant hallenges due to the high interativity requirement and large demand on proessing and network resoures. urthermore, it introdues a new notion of user interation, where partiipants an frequently hange their view orientations in the virtual spae. requent view hanges require frequent updates of multi-stream ontent distribution. ue to this dynami user behavior, even with notable improvements in appliation layer [6][34], today s 3TI struggles with heavy temporal and spatial overheads and multi-stream management omplexities. With the advanement of Software efined ing (SN) researh over the past few years, network omponents have beome aessible and ontrollable from appliation layer [32]. ppliations an use this flexibility to offload 978--4799-27-4/3/$3. 23 I ertain data plane funtionalities to the network layer for the purpose of improving data plane omplexity and effiieny. We have seen the leverage of SN (e.g., Openlow [22]) in different appliations suh as seleting servers for load balaning [3], managing onsisteny in network migration [6], and finding peers for video streaming []. The natural question for us is an we use Openlow network omponents to redue data plane omplexities and improve multi-stream flow management in 3TI. To address this question, we develop, a session-network ross-layer management ontrol protool for managing multi-stream flows in 3TI. introdues a split forwarding arhiteture at the appliation data plane. It partially offloads stream multiast funtionality of the appliation to the SN swithes. If multiple partiipants request the same streams, the soure partiipant sends only single opies of the loal streams to the SN network swith, whih handles multi-stream forwarding to all remote destinations on-behalf-of the appliation. The splitting of data plane redues proessing load at the appliation, and network bandwidth usage at the network. Offloading multistream forwarding to the SN network omponent also improves end-to-end delay in multiast-based streaming beause forwarding of streams is done from the network layer of the SN swithes instead of from the appliation layer of the endhosts at eah multiast hop. However, splitting the data plane introdues several hallenges. irst, the appliation layer multi-stream semantis are lost in the network layer data plane. Without keeping this semantis, the SN swithes annot forward streams aording to the overlay topology. To solve the semanti mapping problem, develops a paket differentiation mehanism that assists the swithes to differentiate data pakets aross multiple streams. Seond, SN provides a fixed interfae (Openlow) to onfigure the network layer data plane. To work with this standard interfae, develops a mapping algorithm to map the multi-stream overlay topology from the appliation layer to the network layer. Third, 3TI requires frequent updates on the data plane onfiguration due to frequent view hanges. To allow fast and seamless view hanges, the updates on the data plane should be performed onsistently aross all partiipants so that the view hanges do not introdue any interferene on streaming. To maintain a global onsisteny while updating the distributed data planes, develops a oordinated route update protool. We implement using Openlow swithes [22] and loodlight ontroller [2]. To prove the benefits of, we run experiments with real 3TI appliation setup among four distributed partiipants (within small geographial
region). To show the impat of larger sale on Internet, we also run distributed 3TI sessions using PlanetLab [26] nodes. Our results show that improves multi-stream 3 streaming performane. It redues end-to-end delay in proportion to the round-trip time (RTT) of loal networks (e.g., a ampus network where the appliation host resides) at eah multiast hop. It also improves bandwidth load within the loal network and proessing load inside the appliation host in proportion to the number of streams in a 3TI session. Though we fous on interative 3TI throughout this paper, does not provide any design limitation that bounds other multi-party tele-onferening appliations to take advantage of it. Our key ontributions are: ) we design and implement, a session-network rosslayer management ontrol plane for multi-stream 3TI using SN support ( IV, 2) we demonstrate ( VI) that improves 3TI interativity in proportion to RTT of the loal network, and redues bandwidth load within the loal network and proessing load inside the appliation host in proportion to the number of streams, and 3) we show ( VI and VII) that makes the data plane resilient against frequent view hanges, route updates and host failures.. 3 Teleimmersion II. KROUN 3TI appliation model: 3TI system is a distributed platform onneting multiple remote sites ontaining a large number of input and output devies (as opposed to traditional video onferening) and reating a virtual shared spae for remote interations as shown in igure. The system ontains three arhitetural tiers. In apturing tier, multiple apturing devies suh as multiple 3 ameras, mirophones, and other hapti sensors apture yber-physial multi-modal information of eah partiipant at his/her physial site. The aptured streams are sent to a loal rendezvous point, alled gateway (, or in igure ), whih is responsible for data dissemination. The dissemination tier onsists of overlay network of gateways multiplexing streams to and from eah site. In rendering tier, streams are synhronously played. 3TI data model: ah 3TI site (or partiipant) hosts multiple 3 stereo ameras; eah aptures a loal sene from various orientations and onstruts a olor-plus-depth 3 stream (S). The seletion of loal streams to transmit to a remote partiipant is alulated based on loal streams orientations and remote partiipant s view (v) demand. or example, if the partiipant is urrently looking at the front of a 3 sene, streams generated by the bak ameras are less important and an be dropped when bandwidth is limited. Views are represented by a set of remote streams in order of their importane in the view. view v by the partiipant at Site- (in igure ) an be represented as v=[s,s,, S n, S n ] for n streams per remote partiipant. The higher number of 3 streams a site reeives (within the available bandwidth), the better quality of 3 virtual environment it reates. Note that individual streams are not merged at the soure, rather transmitted separately, beause it is hard to merge depth maps for all possible view points and merging texture map is omputationally expensive for real-time appliations in terms of lateny. Moreover, the size of the merged stream beomes very large, whih invalidates the notion of dropping less important streams in ase of bandwidth limitation [37]. In addition, 3TI introdues a unique demand, alled view hange, where partiipants an hange their views during a running session. view v i is different from view v j, i.e., v i v j if S v i S 2 v j suh that S S 2. 3TI properties and assumptions: 3TI data streams are transmitted using UP protool, whereas the management ontrol traffi uses TP. Mesh-based overlay multiast routing is used for effiient resoure-aware onstrution of multistream distribution topology. However, the ontrol traffi uses point-to-point onnetivity due to its very low bandwidth requirement. andwidth adaptation (to and from 3TI sites) is done by dropping less important (low priority) streams. The number of users in 3TI is limited beause ) human attention spae is intrinsially bounded [5], and 2) the number of partiipants that an be displayed in the virtual spae is limited due to the pixel spae limitation of the physial display [38].. Software efined ing In Software efined ing, a logially entralized ontroller manages how the network swithes forward pakets in layer-2 and layer-3. The ontroller exhanges ontrol messages with the swithes using a standard protool, suh as Openlow [2]. We use the terms SN and Openlow interhangeably in this paper. The ontrol plane installs forwarding rules to forward pakets in the swith data plane using a flow table with math entry and ation field. Inoming data pakets are mathed against the math entry, and orresponding ations (e.g., forwarding, header modifiation) in the ation field are performed on the mathed pakets.. enefits III. MOTIVTION N HLLNS onsider the senario shown in igure 2(a). Site- generates three streams (for simpliity, we only show streams generating from a single site) S, S2 and S3. S and S2 are distributed to Site-, Site-, and Site- during a running 3TI session. S3 is dropped due to inbound bandwidth limitation. The loal network shown in the figure an be a ampus network, a department network, or a home network. In, streams are forwarded from the network swithes, onneted within the loal network. Loal bandwidth: introdues a signifiant redution of 3TI bandwidth within the loal network of partiipating sites. or example, in igure 2(a), forwarding of streams S and S2 to Site- and Site- is done from the network swith of Site- rather than from its appliation gateway. Therefore, the gateway of Site- does not forward streams S and S2 from the appliation host, whih saves the forwarding bandwidth of S and S2 within the loal network of Site-. It eventually saves the last mile bandwidth to and from the appliation host. andwidth saving also happens at the streaming soure. Though Site- needs to send stream S to both Site- and Site-, only one opy traverses the loal network to the loal Openlow swith, whih performs stream repliation and forwarding.
ig.. a m h Input evies Site- Output r a m h r 3 amera stereo audio mobile sensor hapti sensor renderer Internet Site- Input evies a m h Output r Site- Input evies a m h Output r 3TI appliation model with three sites. Virtual nvironment nd-to-end delay: Sine forwarding of stream from Site- is done from the network layer swith (in igure 2(a)), the endto-end delays (s) of streams S2 from Site- to Site- and Site- are redued by the round-trip time (RTT) of 3 frames in the loal network (d net ) and through the protool stak of the gateway mahine (d app ) at Site-. To measure the order of improvement in, we monitored our ampus network for 3 days from January 5, 23 to January 7, 23. We used four gateway hosts (over wired and wireless links) at different loations within the ampus, and measured point-to-point RTT among them for exhanging 3 frames. The average is about 4ms to 5ms, whih is a signifiant lateny in real-time ommuniation onsidering a single multiast hop. Proessing load: Though igure 2(a) onsiders only forwarding of two streams, multi-stream 3TI onstruts a muh more omplex distribution graph. We have experiened that with the inrease of number of sites and the number of streams per site, the forwarding load (PU load) of 3TI appliation layer gateway inreases linearly. Sine, in, the network layer is responsible for stream repliation and forwarding, the appliation layer is not impated by the inrease of number of subsribers (i.e., partiipants) of a stream. System resilieny: ppliation hosts fail and rash more frequently than underlying network omponents. s separates multiast forwarding from the appliation layer, the failure of an appliation gateway or any rash of appliation due to a software bug at one site does not interfere the realtime ollaborative experiene among other partiipating sites. ailure of does not affet S to Site- in igure 2(a). However, we skip this benefit from the urrent sope.. hallenges Per-stream paket differentiation: To forward streams from the loal Openlow swithes aording to multi-stream overlay distribution graphs, must ensure appliationaware differentiation of network pakets at the swithes. or example, stream S2 (in igure 2(a)) from Site- is forwarded to both Site- and Site-, whereas stream S is only forwarded to Site-. Therefore, the Openlow swith at Site- should be able to differentiate network pakets of S and S2. Openlow standard provides a fixed set of fields to math against inoming pakets [22]. However, organizations usually allow limited open UP ports for seured network. In our setup, we use the same port for multiple streams. Traditional soure and destination address, and soure and destination port based paket differentiation fails sine multiple streams among the sites use the same network layer flow semantis. Therefore, to use the benefit of Openlow-based split data plane arhiteture, we need to ensure two properties in paket S S S 2 S 3 S 2 S 3 Site- S Internet S 2 S gw- 2 Site- Site- (a) Internet S S 2 Loal Openlow Swith Site- Single Rule Insertion Lateny (ms) 3 25 2 5 Trendline f 5 Openlow_Overhead Linear (Openlow_Overhead) 2 4 6 8 low Table Size ig. 2. (a) xample of a 3TI session among 4 sites, (b) Openlow layer-3 rule insertion lateny for different sizes of flow table. differentiation: ) overridden fields are not modified anywhere in the transmission path, and 2) the design does not require any hanges in network omponents or Openlow protool. Overlay to flow table mapping: Next, we need to ensure that flow table rules are onsistently installed at all the partiipating Openlow swithes to follow the stream forwarding ations aording to the overlay. However, blind mapping of overlay to flow tables fails sine it may interrupt other running flows in urrent or onurrent 3TI sessions (e.g., via overriding or superseding available flow table entries). We need to ensure that the flow table size is optimized in the mapping proess. To understand the impat of swith flow table size on 3TI session, we have onduted an isolated experiment with IM 8264 Openlow swith.we measure a single rule insertion lateny for different number of pre-installed rules into the swith. The result is shown in igure 2(b). Wildarded layer-3 rules are stored in a linear table in the TM spae of the swith [3]. s TM is expensive and small, every wildarded layer-3 rule insertion performs an internal optimization of flow tables [4], whih represents signifiant part of the rule insertion lateny. This optimization lateny inreases with the inrease of flow table size, whih impats session initiation and session update lateny. Therefore, we need to ensure two properties while mapping the multi-stream overlay topology to swith flow tables: ) modifiation of flow table does not interrupt on-going forwarding ations, and 2) size of flow table is as small as possible. Seamless view hange: View hange introdues a new human behavior in the multi-stream 3TI environment. If the partiipant at Site- updates a view, whih requests streams S2 and S3 instead of S and S2, then stream S is no longer required by Site-. However, if Site- stops transmission of S to Site-, the streaming path of S to Site- is impated and therefore, should be reonfigured. Sites who are impated by remote view hanges are alled vitim sites. Here, Site- is the vitim site due to the view hange by Site-. To ensure seamless streaming to Site- due to this view hange, the update of streaming path for S to Site- should not interfere the immersive experiene at Site- in terms of paket loss. Therefore, to ensure seamless view hanges, the reation of new topology and the removal of old topology for streams should be performed onurrently. or example, if we update the path in igure 2(a) before removing the path for S, then Site- may get transiently overloaded with redundant S. Likewise, if we remove the path first and then update rules to reate, it introdues temporal disonnetivity of S to Site-. What is required is a onurrent update of distributed flow tables that ensures two properties: no transient ) bandwidth overloading, and 2) network disonnetivity. (b)
IV. OPNSSSION RMWORK ontrol plane ontains three-layer session management hierarhy shown in igure 3 and desribed below. ig. 3. lobal Session ontroller Loal Session ontroller Swith ontroller ontrol path data path T framework. S Site- Site- Site- LS LS LS SRT SW SW ateway gsrt ateway ateway Internet lobal session ontroller: S represents a global ontrol plane, whih is an important design omponent for optimized ontent distribution [8]. S periodially (every few seonds) monitors partiipating sites (suh as streaming rate, 3 onstrution time) and their underlying infrastruture (suh as available inbound and outbound bandwidth and end-toend delay). uring session initiation and session update (suh as view hange), S onstruts an optimized multi-stream overlay ontent distribution topology using global view of the sites (usually 5 to [5]) and their underlying resoures. One the multi-stream topology is omputed, the overlay routing related to eah partiipating site is sent to the orresponding LS. The information is represented by a session routing table or SRT ( V-). In igure 3, we show an example graph orresponding to the SRT of site- for a multi-stream overlay omputed at the S (streams from Site- are only shown). Loal session ontroller: LS is a lightweight (in terms of proessing overhead) session layer. The main responsibility of LS is to update session routing table ( alled gsrt) at the loal gateway (i.e., at the appliation data plane) using the SRT reeived from S ( V-2). ateways use gsrt for the data plane forwarding of loal streams. gsrt ensures that single opies of loal streams are delivered out of the gateway. igure 3 shows an example of gsrt at the gateway of Site-. LS forwards SRT to loal SW to map it to the swith flow table (T). LS is also responsible for monitoring loal devies and resoures, and sends them to S. Swith ontroller: SW diretly ommuniates with the Openlow swithes onneted in the loal network to install forwarding ations defined by SRT ( V-3). n example of forwarding ations in T related to the SRT and gsrt of the previous example is shown in igure 3. SW is also responsible for maintaining onsisteny and size optimization in T. We run SW as a module of the Openlow ontroller. ata plane: The data plane is separated from the management ontrol plane and divided between the appliation gateway and the Openlow swith. The gateways shedule loal streams to multiast remotely based on the onnetivity graph defined by gsrt. The Openlow swithes multiast loal and remote streams based on the forwarding ations defined in T. V. OPNSSSION PROTOOL N UNTIONLITY 3TI Session is initiated by sending a session initiation request to the S, whih ontains a list of sites, a list of loal devies (streams) at eah site, and a list of desired views for all partiipants. esigning an effiient ontent distribution overlay that an ombine different notions of quality (e.g., startup delay, frame rate) and user experiene is an open hallenge that is outside the urrent sope. Here we fous on protools for: () mappings of multi-stream ontent distribution topology to appliation and network layer data planes, and (2) handling of seamless hanges in the distribution topology during session run-time.. Multi-stream Overlay Mapping In this setion, we will disuss, how the multi-stream overlay is mapped into SRT ( V-), gsrt ( V-2) and finally to Openlow T ( V-3). ) Overlay Topology to SRT Mapping: One the multistream overlay topology is omputed, it is mapped to a session routing table (SRT) for eah partiipating site. The mapping of overlay to SRT aims to assoiate forwarding ations with eah stream. SRT ontains three fields: ) Math field (SRT math ) that ontains a stream I, a UP destination port and the gateway IP address of the stream originating site, 2) orwarding ation (SRT ation ) that ontains a list of gateway IP addresses to forward mathing streams to, and 3) irty bit (SRT dirty ) that indiates whether an entry has been modified or not. n example of SRT omputation from a multi-stream overlay is shown in igure 4. or larity, we only show two streams originating from Site- and Site-. The overlay topology omputed by S is shown in igure 4(a). igure 4(b) shows the orresponding SRT of Site-. 2) SRT to gsrt Mapping: The purpose of mapping SRT to gsrt is to define the forwarding responsibility to the appliation layer data plane at the gateway. ah gateway sends only single opies of the loal streams towards the loal Openlow swith, though multiple sites may request the same streams. Streaming towards multiple sites are then done from the Openlow swith via address modifiation (destination IP and M addresses) in the paket header. Therefore, the mapping from SRT to gsrt is done only for loal streams to ensure that the gateway sends only one opy. In igure 4(b), Site- sends stream S to both Site- and Site-. However, the LS only maps the streaming path to Site- in gsrt at Site- (appliation data plane). The streaming to Site- is done from the network layer data plane. igure 4() shows the entries of SRT that are mapped to gsrt. 3) SRT to T Mapping: inally, the mapping of SRT to T is performed by SW in three steps below: Prune SRT entry: We only map dirty SRT entries. Moreover, we prune the SRT entries (assoiated to the loal streams), whih are already assigned to the appliation layer data plane (i.e., to gsrt). or example, in igure 4(b), the SRT entry to forward S (with Math ield 92.68..2 : : 9876) to Site- is pruned and not mapped to T at Site-. However, the SRT entry to forward S to Site- is not pruned. Update math field: fter pruning SRT, we map SRT math field (SRT math ) to T math field (T math ). The Openlow
S = S 2 = 2 S = S 2 = 2 Site- LS ateway 92.68..3 Site- LS ateway 92.68..3 Math ield orwarding ddress irty it ateway I : Stream I : estination Port Math ield orwarding ddress irty it 92.68..2: : 9876 gsrt 92.68..3 ateway I : Stream ateway bit 92.68..2: 2: 9876 92.68..3 I : estination Port ddresses () 92.68..2: : 9876 92.68..3 92.68..3 Math ield orwarding ddress irty it ateway I : Stream ateway bit 92.68..2: 2: 9876 92.68..3 T I : estination Port ddresses Site- LS Site- LS 92.68.5.6: : 9876 92.68..3 92.68..3 92.68..2: : 9876 92.68.5.6: : 9876 92.68..3 92.68..3 SRT of 92.68.5.6: 2: 9876 92.68..3 92.68..3 ateway ateway 92.68.5.6: 2: 9876 92.68..3 92.68.5.6 92.68..2 (a) (b) (d) ig. 4. (a) Multi-stream overlay topology for S, S 2, S, and S 2, (b) the orresponding SRT of Site-, () SRT entries that map to gsrt at Site- (appliation data plane), and (d) SRT entries that map to Openlow T serving at Site- (network data plane). 9876 is UP data ommuniation port. protool allows diret mapping for soure IP address (gw) and destination port (P dst ). However, the notion of appliation layer stream I (S id ) is lost in the network layer data plane. To keep this semanti information in the network layer, we override the higher 5 bits of IP ToS (Type of Servie) field. Overriding of IP ToS bits is very ommon in Internet appliations as they are less frequently used in Internet [7]. When stream data is sent by the gateway, the 8bit IP ToS field of the UP pakets is set based on 5 bits of stream I with zeros in lower 3 bits (i.e., we do not modify N bits used for ongestion ontrol). or example, if S =, the orresponding ToS field in the IP data paket is. Therefore, SRT math = [92.68.5.6. : : 9876] maps to T math = [92.68.5.6. : : 9876]. Update ation list: In addition to forwarding the inoming pakets to the intended destination (based on paket header), the Openlow swithes need to forward the same pakets to other sites (based on SRT ations ) by replaing the destination IP and destination M addresses. If the destination IP is in the remote subnet, uses M address of the gateway-router. lso, the physial port for eah forwarding ation is assigned based on the destination IP. etails are skipped due to brevity. In summary, in addition to forwarding the pakets based on their original headers, we add three ations in T ation field for eah forwarding IP x in SRT ation : ) set destination IP to x, 2) set destination M address to M x, and 3) forward the pakets to port Port x. Here, Port x is the physial port number at the swith that forwards data pakets to destination x, and M x is the M address required to forward data pakets to destination x.. Seamless Session daptation Session adaption (adding or dropping streams) is triggered when partiipants hange views, or bandwidth resoures at the partiipating sites hange. In this setion, we only onsider view hanges; other auses will naturally follow. The result of the view hange is route update for one or more streams. ) Seamless Route Update Problem: s we show in III-, a route update may ause a) overloading when redundant streams are transmitted to any partiipating site), and b) disonnetivity (when streaming of one or more streams beomes temporarily unavailable). To understand the phenomena learly, we show a route update example with six partiipating sites in igure 5(a)-(d) for both overloading and disonnetivity. With frequent view hanges, interative streaming performane at the vitim sites due to transient overloading and disonnetivity beomes very poor. ateway ddresses 2) Route Update Problem ormulation: The route update problem an be mapped to a onstraint-based graph transformation problem. Initially, we will onsider only single stream. Later (in V-5) we will extend our solution for multiple streams. Let us onsider an existing overlay graph ( S old ) and a new overlay graph ( S new) omputed at S after a view hange request. We represent eah graph by a onnetivity matrix M S, where M S [i][j]= if Site-i forwards stream S to Site-j, otherwise M S [i][j]= (note that for the rest of this setion we onsider as, as and so on while indexing the onnetivity matrix). The transformation of graphs an be formulated by their onnetivity matries as follows: raph Transformation Problem: Transform Mold S (onnetivity matrix of S old ) to M new S (onnetivity matrix of S new) for eah stream S, wheremold S M new, S so that the intermediate states of the onnetivity matrix (Mint S ) in the transformation proess do not violate following two onstraints (N= number of sites): ) i M int S [i][j], j N, and 2) Mint S [i][j], if M old S [i][j]=m new[i][j]= S i,j N. onstraint () ensures that there is no transient overloading of S, and (2) ensures that there is no transient disonnetivity. 3) Route Update Solution Overview: To solve seamless route update in, we onsider an additional paket header field (η) in the T math entry. When we add new rules (for the purpose of transforming Mold S to M new) S with a new value in η, the new rules are not mathed against the inoming streams right away, beause inoming streams do not ontain the new value of η in their paket header. In igure 6, we provide an example of how onsideration of an additional math entry (η) in T an solve the route update problem for S as shown in igure 5. elow we desribe. igure 6(a) shows the initial T rules in Site- before the route update. Sine Site- does not forward S, there is no T entry at Site- for stream S. While updating the route from igure 5(a) to igure 5(d), we first add a new T rule at Site- (in igure 6(b)) with math field entry [, S, P dst, η ] (where η is the new value of η) and an ation to forward the mathed stream to Site-. ven though Site- reeives S from Site-, the data pakets are not forwarded to Site- as inoming pakets do not ontain η and are not mathed with the new rule (i.e., no violation of onstraints ()). To initiate the mathing with new entries in T (at Site- ), the Openlow swith at the soure site (at Site-) needs to update η with the new value η in the outgoing paket header while streaming (S ). We replae the T rule at Site- that forwards S to Site- by a new T rule with two ations: ) forward S to Site-, and 2) set η with η in the outgoing paket header. When this rule is inserted at Site-, the data bit
(a) S = S 2 = 2 (b) () isonnetivity Overloading ig. 5. Problem of route update: (a) old overlay graph, (b) disonnetivity at Site-, () overloading to Site-, and (d) new overlay graph. pakets of S towards Site- ontain η in the paket header and are redireted to Site- from Site-. It also terminates the streaming to Site- at the same time (igure 6()). We an ontrol the instant when we want to swith streaming paths onurrently for a stream by modifying T rules at the streaming soure (i.e., onurrently start streaming from Site- to Site- and stop streaming to Site- and Site-). Thus, ensures that the vitim sites are not impated due to the view hange (or any session adaptation) triggered by remote sites unless the updated path reates a large jitter, whih depends on route omputation algorithms. mong other layer-3 and layer-4 fields, we onsider soure port (P sr ) in the UP header as η, beause hanging UP soure port for the outgoing pakets does not violate any routing onstraints. P sr is monotonially inreased with every route update and reset to 24 ( to 23 are speifi purpose ports) when all running 3TI sessions terminate. Note that gateways do not modify P sr in the paket header, rather the Openlow swith performs the replaement on the outgoing pakets of the loal streams. If we update P sr in the Ts only at the sites impated by a route update, soon there will be different values of P sr in the Ts aross all sites with the same soure IP, UP destination port and IP ToS bits, whih may reate inonsisteny in future T update. Therefore, when a route update happens for stream S, all distributed T rules that forward S are updated and start mathing η in the P sr math field. elete obsolete rules: When inoming streams are mathed against the new rules, old rules beomes obsolete and are deleted automatially using the Openlow-defined timeout primitive. or a T entry, if there are no mathing pakets for a ontinuous interval defined by idle_timeout, the rule will be deleted from the swith. We speify 3se idle_timeout. Openlow also uses a hard_timeout, whih removes the rule from T after the timeout even mathing flows exist. uses infinite hard_timeout. 4) Route Update lgorithm: Summarizing the above disussion, ) we need to speify a new η eah time a route update happens, and 2) T entries in the remote sites need to be updated first before updating the T entries at the soure site (igure 6(a)-()). elow we formally present the distributed route update algorithm at different ontroller levels. Route update at S: S is responsible for initiating the route update. epending on Mnew S and Mold S, S lassifies Site-i into four states (a site an be in multiple states): ) No-route Site-i not forwarding S to any site before and after the route update ( j M S old [i][j]= M S new[i][j]=), 2) rop-route Site-i drops forwarding S to any site after the route update ( j M S old [i][j]= M S new[i][j]=), (d) to tion Math Math tion [, S orward to, 9876] to [, S, 9876] orward to orward to to orward to & η=η orward to to to to Math tion Math tion [, S, 9876, η ] orward to [, S, 9876, η ] orward to (a) (b) () ig. 6. (a)-() Sequene of T updates for a seamless route update of S for the ase shown in igure 5. 9876 is the data ommuniation port. 3) dd-route Site-i starts reeiving S from any site after the route update ( j M S old [j][i]= M S new[j][i]=), and 4) Keep-route Site-i keeps reeiving S from same site after the route update ( j M S old [j][i]= M S new[j][i]=). If a site is in no-route state, no updates in SRT and T are required and no messages are sent to the site s LS. If a site is only in drop-route state, no SRT and T updates are required (at non-origin sites). Obsolete entries (no math for η ) are removed by the timeout. If a site is in keep-route state, though there is no update required in SRT, an update in T is still required to assign P sr =η in the T math entry ( V-3). route update request message Ω T is sent to the site s LS. If a site is in add-route state, we need to update both T and SRT to reflet the hanges in the forwarding paths at Site-i. In this ase, S sends a route update message Ω SRT T to the site s LS. If a site is in multiple states, the route update messages orresponding to the states are sent umulatively to the site s LS. Messages Ω T and Ω SRT T are sent onurrently to all sites exept at the soure site of S. fter all sites update their tables (SRT and T), S sends a route update request message to the soure site. or the soure site, the seletion of route update message is also made based on its state. However, even the soure site is at drop-route state (i.e., streaming to one or more remote sites is dropped), we still need to send Ω SRT message to update gsrt. ah route update message ontains new SRT (SRT new ) with all dirty bits set to (sine we need to update P sr for all entries), and η. To ensure the ordering of route update requests, S onstruts a depth first traversal (T) of sites from M S new and sends route update requests to all sites onurrently exept the last site in the order, whih is the soure site. One route update requests are replied by all sites, then a route update message is sent to the soure site to perform an atomi swith from M S old to M S new. Route update at LS: When Ω T or Ω SRT T is reeived at LS for remote streams, it simply forwards the message to SW. However, for the loal streams, LS updates gsrt using SRT new using the algorithm disussed in V-2 and then forwards the message to SW. Route update at SW: When SW reeives route update message Ω T or Ω SRT T, it maps the rules from SRT new to T with P sr =η. Proess for handling route update messages at the soure site is the same, exept P sr is not onsidered in the T math entry field for S, and an additional ation is added in the T ation list to replae P sr with η in the outgoing pakets of S. We modify our mapping algorithm in V-3 to inorporate P sr, however we skip it for brevity. To ensure that the rule has been added to the T entry, a barrier message is sent to the swith [22]. Reply of the barrier message onfirms that the previous ommand for rule insertion is ompleted suessfully. One T entries are updated suessfully, a onfirmation is sent to the S. igure 7 shows an example of seamless route update proess for the update of stream S.
S old M old S rops S Transform new S M new S η = η + T order (i) M S old [i][j] M S new [i][j] State no-route add-route no-route add-route keep-route drop-route keep-route Route Update Message N/ Ω SRT_T N/ Ω SRT_T Ω SRT_T Ω T S Ω SRT_T Ω T ΩSRT_T Ω SRT_T onurrent route update Reply route update Soure route update (a) (b) () 2 3 Order of messages ig. 7. xample of route update proess for a single stream: (a) route update due to Site- drops stream S, (b) route update messages and omputed state of the sites due to the route update, and () route update protool showing the order of route update messages. 5) Multi-stream Route Update: uring a view hange, if routes of multiple streams are required to update in the new overlay, performs soure-based route update as shown in V-4 for all modified streaming paths in parallel. The route update messages (in igure 7(d)) are sent umulatively for all streams. However, the parallel route updates an be dependent if the updates of routes overlap at any site. or example, if Site-i drops (adds) forwarding (reeiving) of S and adds (drops) forwarding (reeiving) of S in the new overlay during session adaptation, the route updates for S and S beome dependent as the updates overlap at Sitei. It is hallenging to guarantee seamless session adaptation when route-update dependenies exist (though rare) among streams from different soure sites. The soure-based route update annot guarantee atomi update of routes for S and at Site-i as streams are originating from separate soures. S To ensure seamless route update at all sites, onsiders a route update onstraint at S for omputing new multi-stream overlay: (RU) if a site drops (adds) forwarding (reeiving) of Sx, i it does not add (drop) forwarding (reeiving) of Sy j in the same route update proess for any x and y where i j. Sites violating RU may not experiene seamless adaptation. Note that view hanges do not violate RU sine during a view hange i=j (i.e., streams ome from the same site). lso, when lower priority streams are dropped due to network ongestion, the overlay modifiation does not usually violate RU. RU is a natural onstraint, and in most of the ases, RU remains valid. etails are skipped due to brevity. VI.. valuation Setup VLUTION WITH RL 3TI STUP We setup 4 3TI sites (in igure 8(a)) in different types of networks. Site- is in a home network, where the Openlow swith is plaed next to the gateway. Site- is in a ampus network, where the Openlow swith is plaed within the ampus network. Site- is in a ompany network, where the Openlow swith is plaed loser to the ompany s network edge. Site- is in a department network, where Openlow swith is plaed loser to the department s network edge. ah site ontains 8 video streams apturing partiipants 3 stereosopi image from 45 apart and onstruts a meshbased olor-plus-depth 3 image. Instead of using physial ameras, we read streams from stored files, whih already ontain the 3 video of the partiipants for hour session. Streams are read at the original frame rate. verage bandwidth Site- ampus INTRNT Site- S 3 streams Offie ampus Site- (a) epartment Site- LS SW ateway Loal Streams of Site- Loal Streams of Site- (b) Loal Streams of Site- Loal Streams of Site- ig. 8. (a) 3TI setup with 4 sites, and (b) priority-driven multi-stream ontent distribution overlay graphs for loal streams of eah site. of eah 3 stream is about.5 to 2.Mbps. ah appliation node (site) hosts a gateway to multiplex transmission of loal streams. We plae LS on the same gateway host and implement SW as a module of loodlight [2] ontroller running on a separate host at eah site. ll ontrol ommands use TP and data traffi uses UP. We use Openlow software swithes with ps port apaity. Initially, all sites request the same set of remote streams. ue to the notion of stream priority, eah view demands only 4 streams from eah remote partiipant (overing 8 spae). The initial multi-stream overlay is onstruted using the topology shown in igure 8(b). However, during the session run-time, the overlay is updated to meet the view hange demands. We ompare the performane of to a no ase, where the gateway performs the sole data plane funtionality without using the network support.. Performane Metris To measure the appliation performane, we run the same 3TI session with and without the ontrol plane. No view hange is requested. ah performane value is measured, in perentage, with respet to the measurement olleted without using (i.e., no ). Loal bandwidth: ahieves a signifiant redution in bandwidth within the loal network. We divide the bandwidth usage into two parts. irst, we plot how muh bandwidth we use within the loal network between the gateway and the Openlow swith at eah site. We notie that (in igure 9) Site-, Site- and Site- ahieve about 55% redution in bandwidth for loal streams in. Seond, we plot how muh bandwidth we use within the loal
ig. 9. Relative Value (%) 8 6 4 2 Loal Stream andwidth 8 6 4 2 Loal Stream andwidth No 7.2 Mbps No 7.36 Mbps 22.34 Mbps Remote Stream andwidth elay 22.36 Mbps (a) Site- Remote Stream andwidth (b) Site- 2.36 ms 9.53 ms elay 5.6% Proessing Overhead 5.6% Proessing Overhead 8 6 4 2 8 6 4 2 7.84 Mbps Loal Stream andwidth Loal Stream andwidth No 22.32 Mbps Remote Stream andwidth No 8.58 Mbps 22.7Mbps () Site- Remote Stream andwidth (d) Site- 7.23 ms elay 5.89 ms elay 5.6% 5.6% Proessing Overhead Proessing Overhead (a)-(d) The relative value (with respet to the measurements without ) of performane metris in a 3TI session at different sites. network for the remote streams. The redues about 35% bandwidth for the remote streams. Proessing Load: We measure proessing load of the gateway, whih inludes stream reeiving, sheduling and forwarding load of the appliation. s shown in igure 9, lowers stream sheduling and forwarding load at the appliation layer data plane by offloading part of the forwarding funtionalities to the network layer data plane. On average, the improves PU overheads by 42% per site. nd-to-end delay: The gain in network transmission delay is ahieved in as streams do not traverse the loal network for multiast-based forwarding at eah multiast hop. We ahieve about 45% gain (about 8ms) in the end-toend network delay (will be higher for wireless end host) for transmitting 3 frames from the soure to the destination site.. Impat of View hange Views are hanged aording to the Zipf distribution of 2 pre-seleted view orientations (22.5 apart). view hanges are requested from one site (Site-) within hour at equal interval. Routes for the impated streams are updated onsidering onstraints RU ( V-5). Valid peers (not violating RU) to update streaming paths are seleted randomly. No streams are dropped after session adaptation. View hange lateny: View hange lateny is measured as the differene between the time when a view hange is requested by Site- and the time when Site- reeives new streams aording to the view demand. In no ase, after omputing the updated overlay at the S, the appliation data plane at the gateway is updated without onsidering the impat on vitim sites. In, the view hange lateny inludes the steps shown in igure 7. We plot of view hange lateny in igure with and without. The additional overhead in view hange by ontrol is very small (<5ms). View hange resilieny: ahieves view hange resilieny sine vitim sites are not overloaded or disonneted during view hanges. However, in no, if distributed flow tables are updated without maintaining any partiular order, paket losses our at the vitim sites. To.8.6.4 No.2 3 5 7 9 3 ig.. View hange Lateny (ms) View hange lateny (lateny between the sites is 5-2ms). measure the gain in view hange resilieny with, we run the same 3TI session with and without. Pakets are dropped if disonnetivity ours in streaming at the vitim sites. Table I shows the total number of paket losses per view hange for all streams at all vitim sites. It is evident that provides higher resilieny in view hange. TL I. NUMR O PKT LOSSS U TO VIW HN pproahes vg Stdev Max Min No 2.35 9.2 45 9 VII. VLUTION WITH PLNTL We use PlanetLab to evaluate the performane of under real Internet artifats in real-time 3TI streaming.. valuation Setup To run 3TI in PlanetLab nodes, we ollet 5 nodes from different geographial regions. or eah 3TI session, we randomly selet nodes. ah node hosts one gateway, one LS and one SW. s we do not have aess to the network omponents of the remote nodes, we develop a swith appliation (keeps T in memory) that uses f (from igure 2(b)) to simulate the rule insertion lateny. The endto-end delays are less than 8ms and inbound and outbound bandwidths are within Mbps and 25Mbps, respetively. We onsider three overlay onstrution approahes shown below due of their lose relation to multi-stream 3TI appliations. Random: In the Random approah, a random multi-stream topology is onstruted during session initiation. It does not
.8.6.4.2 OSM Random Viewast 75 25 75 225 275 (a) View hange Lateny (ms).8 OSM.6 Random.4 Viewast.2 3 5 7 9 (b) Number of Sites Update Ts in View hange ig.. or different overlay omputation approah in PlanetLab setup, (a) view hange lateny, and (b) number of sites update flow tables. onsider stream priority. uring view hanges, streaming soures are seleted randomly. Viewast: In Viewast [37], initial multi-stream overlays are onstruted onsidering the stream priority. uring view hanges, the higher priority streams (among the impated streams) are restored (randomly) first. Though Viewast is a distributed algorithm, we implement it in a entralized. way. OSM: In OSM [5], the initial multi-stream overlays are onstruted using evolutionary optimization to ensure a globally optimized overlay onsidering stream priority. uring view hanges, optimal streaming paths are seleted for the streams.. Impat of View hange View hange overhead: igure (a) shows of view hange lateny inurred in with three different overlay onstrution algorithms. Though OSM auses larger view hange lateny, the overhead mainly omes from the optimization proess for the omputation of the new overlay after a view hange is requested. The average overlay omputation latenies for OSM, Random and Viewast are.3se, 87ms and 763ms, respetively. Sine the update of flow tables for a view hange ours at all sites in parallel exept at the soure site, the ommuniation lateny is proportional to the two round-trip delays between the partiipating sites and the S. igure (b) shows the of number of sites update their flow tables over view hanges. Most of the ases, 7% of the sites are required to update their Ts. The number of sites here orresponds to the message overhead during a view hange. The message overhead of protool is very small sine the size of a route update message is 4, whih leads to about 2.8K overhead per view hange. View hange resilieny: To understand the impat of view hange resilieny in PlanetLab setup, we run 3TI sessions among the PlanetLab nodes with and without. In no, T rules are updated in two different orderings aross the distributed site-gateways when view hanges are requested. In the first ase (ase-i), we update T rules allowing overloading but no disonnetivity on the streaming path. In the seond ase (ase-ii), we update T rules allowing disonnetivity, but no overloading on the streaming path. Over hour experiment, we modify the number of view hanges Paket Loss 5 (b).95.9.85.8.75.7 5 bursts No : ( View hanges/ Hour) No : (2 View hanges/ Hour) No : (5 View hanges/ Hour) : (5 View hanges/ Hour) 36 36.5 37 37.5 38 38.5 39 39.5 4 4.5 4 4.5 42 42.5 43 (a) Inbound andwidth to Vitim Site (Mbps) No 5 5 2 25 3 35 4 45 5 Number of View hanges in Hour 3TI Session ig. 2. Impat of view hange frequeny on (a) inbound bandwidth to the vitim site, and (b) total number of paket loss for all streams during hour. to get different view hange frequeny. We onsider Random overlay onstrution. igure 2(a) plots the of average inbound bandwidth at the vitim sites measured in 5 seonds interval during hour session for ase-i. Without, overloading reates a sudden burst in the inbound bandwidth of the vitim sites. The number of bursts inreases with the inrease of view hange frequeny. However, in, the inbound bandwidth is fairly onstant even with higher view hange frequeny. igure 2(b) shows the total average number of paket losses at the vitim sites for all streams for ase-ii over hour session. Without, the number of paket losses inreases linearly with the inrease of view hange frequeny due to the frequent disonnetivity. However, does not reate any paket loss at the vitim sites due to view hanges. Similar resilieny an be shown for site failures.. Overhead s we implement SW inside the loodlight Openlow ontroller, there is an extra proessing overhead in the ontroller. To measure this overhead, we use the benh ontroller benhmarking tool [23]. We run benh in throughput mode, emulating swith onneted to one site. We are able to proess 225283 paket_in events per seond as ompared to 24768 in loodlight without (6% overhead). VIII. RLT WORK Multiast routing protool: IP multiasting protools (e.g., PIM-SM [], MON []) do not provide any appliation layer programmable interfae at the routers and global ontrol for run-time dynami onfigurations. To physially deploy PIM-SM, a dependeny aross ISPs is required, whih ISPs do not allow. MON overomes the ISP dependeny by reating a virtual multiast network. However, it requires a fixed additional bakbone and does not sale. Via, we suessfully enable quality of servie ontrol over some parts (last miles) of the Internet end-to-end data transmission paths without inter-domain ontrol aross ISPs. ontrol resides only inside the loal network and only for 3TI appliation-speifi traffi. Multimedia session ontrol protool: SIP is a session layer signaling protool [29] used for session management in IP telephony and VoIP servies. SIP does not provide mehanisms
to onfigure data plane for streaming. Other session protools like RTP [3] uses in-band ontrol funtionalities over data to assist streaming, and RTP [3] is out-of-band ontrol protool for RTP. Liu et al. [8] propose to deouple data and ontrol arhiteture for Vo streaming, however the fous is more on the server (N) seletion. 4 Teleast [4] provides a ontrol arhiteture for session management in 3TI, but it only aims for non-immersive viewers. Multimedia flow management: The efforts of ross-layer multimedia flow management an be divided into three ategories: resoure reservation (e.g., [2], [8]), routing (e.g., [35]) and flow sheduling (e.g., [33]). Unlike RSVP, does not require ontrol of network routers inside the ISPs for the feasibility onern. onsiders layer-3 ontrol over wide-area-networking and so, MPLS [28] and other layer-2 quality ontrol protools do not work. long with different overlay routing approahes [2], various appliation layer resoure reservation and sheduling tehniques an still be performed within framework. ppliation support with Openlow: Openlow is part of the Stanford University s lean slate projet. Openlow swithes are ontrolled and modified by Openlow ontroller, enabling flexible funtions suh as flow forwarding, rediretion, multiast, routing, and others (e.g., [2], [25], [3]). Openlow has been used in data enters (e.g., [3], [36], [6]) and assisting in salable video streaming (e.g., []). IX. ISUSSION N ONLUSION protool adds following features in urrent real-time ollaborative appliations (onsidering igure 9): Simplified data plane: The separation of data and ontrol plane in makes appliation logi simpler. urthermore, the partial offloading of appliation data plane to the network layer redues multi-stream management and forwarding overhead of the appliation host (about 42%). Improved appliation performane: The splitting of data plane omes with the benefits of lower bandwidth overhead (over 55% for loal streams and 35% for remote streams) within the loal network (i.e., last mile) and lower network transmission delay (over 45%) in multiast-based streaming. Seamless session adaptation: handles vitim sites in session adaptation proess and seamlessly updates the running session without introduing any streaming interferene (paket loss or traffi burst) at the vitim sites. The improvement is shown by a demo video in [24]. Optimized ontrol plane: optimizes the flow table size at the Openlow swithes. The swith ontroller does not keep any state, and the proessing overhead at the ontroller is very small (about 6%). We have shown that in addition to the great potential of SN in data enter, it an be used very effiiently for wide area interative networking appliations like 3TI. suessfully leverages the network layer funtionality to improve appliation performane in 3TI. RRNS [] S. eering et al. The PIM arhiteture for wide-area multiast routing. Transations on ing, 996. [2] K. ndreev et al. esigning overlay multiast networks for streaming. In SP, 23. [3] M. ppelman et al. Performane analysis of Openlow hardware. http://bit.ly/snlt. [4]. refin et al. 4 Teleast: towards large sale multi-site and multi-view dissemination of 3TI ontents. In IS, 22. [5]. refin et al. Prioritized evolutionary optimization in open session management for 3 tele-immersion. In MMSys, 23. [6] H. H. aker et al. Understanding performane in oliseum, an immersive videoonferening system. In TOMP, 25. [7] W. eyda et al. System and method for reinterpreting TOS bits. USPatent76737, 26. [8]. raden et al. Resoure Reservation ProtoolR 225, 997. [9] iso TelePresene Video onferening. http://bit.ly/2njp, 27. [] H.. gilmez et al. Salable video streaming over Openlow networks: n optimization framework for QoS routing. In IIP, 2. [] H. riksson. Mbone: the multiast bakbone. ommun. M, 994. [2] loodlight. http://floodlight.openflowhub.org/. [3] N. Handigol et al. Plug-n-server: Load balaning web traffi using Openlow. In SIOMM, 29. [4]. Hedlund. On data enter sale, Openlow, and SN. http://bit.ly/gljiz. [5]. Kahneman. Thinking, fast and slow. 2. [6]. Keller et al. Live migration of entire network (and its hosts). In HotNets, 22. [7]. Kurillo et al. Real-time 3 avatars for tele-rehabilitation in virtual reality. Studies in health tehnology and informatis, 2. [8] X. Liu et al. ase for a oordinated Internet video ontrol plane. In SIOMM, 22. [9]. Maimone et al. Real-time volumetri 3 apture of room-sized senes for telepresene. In 3TV-ON, 22. [2] N. MKeown et al. Openlow: enabling innovation in ampus networks. In SIOMM R, 28. [2] P. L. Montessoro. ffiient management and pakets forwarding for multimedia flows. and System Management, 22. [22] Openlow. www.openflow.org. [23] Openlow ontroller benhmark. http://bit.ly/upa5m7. [24] Seamless Route Update. http://bit.ly/3oepn. [25] M. Othman et al. esign and implementation of appliation based routing using Openlow. In I, 2. [26] PlanetLab. http://http://planet-lab.org/. [27] Polyom. http://bit.ly/vkx7po, 27. [28]. Rosen et al. P/MPLS IP Virtual Private s (VPNs) R 4364, 26. [29] J. Rosenberg et al. Session initiation protool (R 326), 22. [3]. Rotsos et al. OLOPS: an open framework for Openlow swith evaluation. In PM, 22. [3] H. Shulzrinne et al. RTP: a transport protool for real-time appliations, (R 355), 23. [32] Software-efined ing. http://bit.ly/lpv2l, 22. [33] L. Toni et al. Multi-view video paket sheduling. arxiv:22.4455. [34] H. Towles et al. 3 tele-ollaboration over internet2. In ITP, 22. [35] R. Vogel et al. Qos-based routing of multimedia streams in omputer networks. Seleted reas in ommuniations, 996. [36] R. Wang et al. Openflow-based load balaning gone wild. In HotI, 2. [37] Z. Yang et al. nabling multi-party 3 tele-immersive environments with Viewast. In TOMP, 2. [38]. Yu. MyView: ustomizable automati visual spae management for multi-stream environment. Ph Thesis, 26. [39] Z. Zhang et al. emo: Sword fight with smartphones. In SenSys, 2.