-
OpenSession: SDN-based Cross-layer Multi-streamManagement
Protocol for 3D Teleimmersion
Ahsan Arefin Raoul Rivas Rehana Tabassum Klara
NahrstedtUniversity of Illinois at Urbana-Champaign, Urbana,
IL{marefin2, trivas, tabassu2, klara}@illinois.edu
Abstract—Video conferencing applications pose
fundamentallydifferent service requirements than traditional data
traffic onthe Internet. Strong real-time interactivity is very
importantamong participants unlike video streaming in VoD
applications.Requirements are even more stringent in multi-stream
and multi-site teleimmersive applications due to strong
dependencies acrossgeographically distributed streams. In this
paper, we proposeOpenSession, a cross-layer session-network control
protocol formulti-stream multi-site 3D teleimmersion (3DTI) that
improvesinteractivity, resource utilization and scalability.
OpenSessiondecouples application layer data and control plane
functionalities,and partially offloads the data plane
functionalities to networklayer switches. To control network layer
switches during thesession run-time, OpenSession leverages support
from SoftwareDefined Networking (e.g., OpenFlow). Through extensive
evalua-tion with multi-stream 3D teleimmersion among four
distributedsites and PlanetLab-based larger 3DTI setup, we show
thatOpenSession improves 3DTI interactivity and resource usageat
the data plane. Furthermore, OpenSession keeps data planerobust
against host failures and frequent route updates.
I. INTRODUCTION
We have seen a surge of interest in telepresence
videocollaborative technologies over the past few years. Though
theinitial focus was on video conferencing application
[9][27],emerging is the 3D teleimmersion (3DTI) technology
thatexpands the horizon by supporting full-body interaction
ofphysical activities in virtual environments. Applications
havebeen found in rehabilitation, collaborative dancing, and
onlinegaming (e.g., [17], [39]) in addition to video conferencing
[19].
3DTI consists of a real-time correlated multi-stream
en-vironment, where distributed participants interact with
eachother in a shared virtual space by fusing streams from
multiple3D cameras, microphones and other sensors. Despite
greatpotential, today’s multi-stream 3DTI still faces
significantchallenges due to the high interactivity requirement and
largedemand on processing and network resources. Furthermore,
itintroduces a new notion of user interaction, where
participantscan frequently change their view orientations in the
virtualspace. Frequent view changes require frequent updates
ofmulti-stream content distribution. Due to this dynamic
userbehavior, even with notable improvements in application
layer[6][34], today’s 3DTI struggles with heavy temporal andspatial
overheads and multi-stream management complexities.
With the advancement of Software Defined Networking(SDN)
research over the past few years, network componentshave become
accessible and controllable from applicationlayer [32].
Applications can use this flexibility to offload
certain data plane functionalities to the network layer for
thepurpose of improving data plane complexity and efficiency.We
have seen the leverage of SDN (e.g., OpenFlow [22]) indifferent
applications such as selecting servers for load balanc-ing [13],
managing consistency in network migration [16], andfinding peers
for video streaming [10]. The natural questionfor us is “can we use
OpenFlow network components toreduce data plane complexities and
improve multi-stream flowmanagement in 3DTI”. To address this
question, we developOpenSession, a session-network cross-layer
management con-trol protocol for managing multi-stream flows in
3DTI.
OpenSession introduces a split forwarding architecture atthe
application data plane. It partially offloads stream
multicastfunctionality of the application to the SDN switches. If
mul-tiple participants request the same streams, the source
partici-pant sends only single copies of the local streams to the
SDNnetwork switch, which handles multi-stream forwarding to
allremote destinations on-behalf-of the application. The
splittingof data plane reduces processing load at the application,
andnetwork bandwidth usage at the network. Offloading multi-stream
forwarding to the SDN network component also im-proves end-to-end
delay in multicast-based streaming becauseforwarding of streams is
done from the network layer of theSDN switches instead of from the
application layer of the end-hosts at each multicast hop.
However, splitting the data plane introduces several
chal-lenges. First, the application layer multi-stream semantics
arelost in the network layer data plane. Without keeping
thissemantics, the SDN switches cannot forward streams accordingto
the overlay topology. To solve the semantic mapping prob-lem,
OpenSession develops a packet differentiation mechanismthat assists
the switches to differentiate data packets acrossmultiple streams.
Second, SDN provides a fixed interface(OpenFlow) to configure the
network layer data plane. Towork with this standard interface,
OpenSession develops amapping algorithm to map the multi-stream
overlay topologyfrom the application layer to the network layer.
Third, 3DTIrequires frequent updates on the data plane
configuration dueto frequent view changes. To allow fast and
seamless viewchanges, the updates on the data plane should be
performedconsistently across all participants so that the view
changesdo not introduce any interference on streaming. To maintain
aglobal consistency while updating the distributed data
planes,OpenSession develops a coordinated route update
protocol.
We implement OpenSession using OpenFlow switches [22]and
Floodlight controller [12]. To prove the benefits of OpenS-ession,
we run experiments with real 3DTI application setupamong four
distributed participants (within small
geographical978-1-4799-1270-4/13/$31.00 c©2013 IEEE
-
region). To show the impact of larger scale on Internet, wealso
run distributed 3DTI sessions using PlanetLab [26] nodes.Our
results show that OpenSession improves multi-stream3D streaming
performance. It reduces end-to-end delay inproportion to the
round-trip time (RTT) of local networks(e.g., a campus network
where the application host resides)at each multicast hop. It also
improves bandwidth load withinthe local network and processing load
inside the applicationhost in proportion to the number of streams
in a 3DTI session.
Though we focus on interactive 3DTI throughout thispaper,
OpenSession does not provide any design limitationthat bounds other
multi-party tele-conferencing applicationsto take advantage of it.
Our key contributions are: 1) wedesign and implement OpenSession, a
session-network cross-layer management control plane for
multi-stream 3DTI usingSDN support (§IV, 2) we demonstrate (§VI)
that OpenSessionimproves 3DTI interactivity in proportion to RTT of
the localnetwork, and reduces bandwidth load within the local
networkand processing load inside the application host in
proportionto the number of streams, and 3) we show (§VI and §VII)
thatOpenSession makes the data plane resilient against frequentview
changes, route updates and host failures.
II. BACKGROUND
A. 3D Teleimmersion
3DTI application model: 3DTI system is a distributed plat-form
connecting multiple remote sites containing a largenumber of input
and output devices (as opposed to tradi-tional video conferencing)
and creating a virtual shared spacefor remote interactions as shown
in Figure 1. The systemcontains three architectural tiers. In
capturing tier, multiplecapturing devices such as multiple 3D
cameras, microphones,and other haptic sensors capture
cyber-physical multi-modalinformation of each participant at
his/her physical site. Thecaptured streams are sent to a local
rendezvous point, calledgateway (A, B or C in Figure 1), which is
responsible fordata dissemination. The dissemination tier consists
of overlaynetwork of gateways multiplexing streams to and from
eachsite. In rendering tier, streams are synchronously played.
3DTI data model: Each 3DTI site (or participant) hostsmultiple
3D stereo cameras; each captures a local scenefrom various
orientations and constructs a color-plus-depth3D stream (S). The
selection of local streams to transmitto a remote participant is
calculated based on local streams’orientations and remote
participant’s view (v) demand. Forexample, if the participant is
currently looking at the frontof a 3D scene, streams generated by
the back cameras areless important and can be dropped when
bandwidth is limited.Views are represented by a set of remote
streams in order oftheir importance in the view. A view v by the
participant atSite-C (in Figure 1) can be represented as v=[SA1
,S
B1 , · · · , SAn ,
SBn ] for n streams per remote participant. The higher numberof
3D streams a site receives (within the available bandwidth),the
better quality of 3D virtual environment it creates.
Note that individual streams are not merged at the source,rather
transmitted separately, because it is hard to mergedepth maps for
all possible view points and merging texturemap is computationally
expensive for real-time applicationsin terms of latency. Moreover,
the size of the merged stream
becomes very large, which invalidates the notion of droppingless
important streams in case of bandwidth limitation [37].In addition,
3DTI introduces a unique demand, called viewchange, where
participants can change their views during arunning session. A view
vi is different from view vj , i.e.,vi 6= vj if ∃S1 ∈ vi ∧ S2 ∈ vj
such that S1 6= S2.
3DTI properties and assumptions: 3DTI data streams
aretransmitted using UDP protocol, whereas the managementcontrol
traffic uses TCP. Mesh-based overlay multicast routingis used for
efficient resource-aware construction of multi-stream distribution
topology. However, the control traffic usespoint-to-point
connectivity due to its very low bandwidthrequirement. Bandwidth
adaptation (to and from 3DTI sites)is done by dropping less
important (low priority) streams. Thenumber of users in 3DTI is
limited because 1) human attentionspace is intrinsically bounded
[15], and 2) the number ofparticipants that can be displayed in the
virtual space is limiteddue to the pixel space limitation of the
physical display [38].
B. Software Defined Networking
In Software Defined Networking, a logically
centralizedcontroller manages how the network switches forward
pack-ets in layer-2 and layer-3. The controller exchanges
controlmessages with the switches using a standard protocol, suchas
OpenFlow [20]. We use the terms “SDN” and “OpenFlow”interchangeably
in this paper. The control plane installs for-warding rules to
forward packets in the switch data plane usinga flow table with
match entry and action field. Incoming datapackets are matched
against the match entry, and correspond-ing actions (e.g.,
forwarding, header modification) in the actionfield are performed
on the matched packets.
III. MOTIVATION AND CHALLENGES
A. Benefits
Consider the scenario shown in Figure 2(a). Site-A gen-erates
three streams (for simplicity, we only show streamsgenerating from
a single site) SA1 , S
A2 and S
A3 . S
A1 and S
A2
are distributed to Site-B, Site-C, and Site-D during a
running3DTI session. SA3 is dropped due to inbound
bandwidthlimitation. The local network shown in the figure can be
acampus network, a department network, or a home network.In
OpenSession, streams are forwarded from the networkswitches,
connected within the local network.
Local bandwidth: OpenSession introduces a significantreduction
of 3DTI bandwidth within the local network ofparticipating sites.
For example, in Figure 2(a), forwardingof streams SA1 and S
A2 to Site-C and Site-D is done from
the network switch of Site-B rather than from its
applicationgateway. Therefore, the gateway of Site-B does not
forwardstreams SA1 and S
A2 from the application host, which saves the
forwarding bandwidth of SA1 and SA2 within the local network
of Site-B. It eventually saves the last mile bandwidth to
andfrom the application host. Bandwidth saving also happens atthe
streaming source. Though Site-A needs to send stream SA1to both
Site-B and Site-D, only one copy traverses the localnetwork to the
local OpenFlow switch, which performs streamreplication and
forwarding.
-
A B
Internet
r
r m
c a
h r
3D camera stereo audio mobile sensor haptic sensor renderer
Site-A
Site-B
c c c c
c c c c
a m
h
c c c c
c c c c
a m
h Input Devices
Input Devices Output
Output
C
r
Site-C
c c c c
c c c c
a m
h
Input Devices Output Virtual Environment
Fig. 1. 3DTI application model with three sites.
End-to-end delay: Since forwarding of stream from Site-B isdone
from the network layer switch (in Figure 2(a)), the end-to-end
delays (EEDs) of streams SA2 from Site-A to Site-C andSite-D are
reduced by the round-trip time (RTT) of 3D framesin the local
network (dnet) and through the protocol stack ofthe gateway machine
(dapp) at Site-B. To measure the order ofimprovement in EED, we
monitored our campus network for3 days from January 15, 2013 to
January 17, 2013. We usedfour gateway hosts (over wired and
wireless links) at differentlocations within the campus, and
measured point-to-point RTTamong them for exchanging 3D frames. The
average EED isabout 4ms to 5ms, which is a significant latency in
real-timecommunication considering a single multicast hop.
Processing load: Though Figure 2(a) considers only forward-ing
of two streams, multi-stream 3DTI constructs a much morecomplex
distribution graph. We have experienced that with theincrease of
number of sites and the number of streams persite, the forwarding
load (CPU load) of 3DTI application layergateway increases
linearly. Since, in OpenSession, the networklayer is responsible
for stream replication and forwarding, theapplication layer is not
impacted by the increase of number ofsubscribers (i.e.,
participants) of a stream.
System resiliency: Application hosts fail and crash more
fre-quently than underlying network components. As
OpenSessionseparates multicast forwarding from the application
layer, thefailure of an application gateway or any crash of
applicationdue to a software bug at one site does not interfere the
real-time collaborative experience among other participating
sites.Failure of B does not affect SA1 to Site-C in Figure
2(a).However, we skip this benefit from the current scope.
B. Challenges
Per-stream packet differentiation: To forward streams fromthe
local OpenFlow switches according to multi-stream over-lay
distribution graphs, OpenSession must ensure application-aware
differentiation of network packets at the switches. Forexample,
stream SA2 (in Figure 2(a)) from Site-B is forwardedto both Site-C
and Site-D, whereas stream SA1 is only for-warded to Site-C.
Therefore, the OpenFlow switch at Site-B should be able to
differentiate network packets of SA1 andSA2 . OpenFlow standard
provides a fixed set of fields to matchagainst incoming packets
[22]. However, organizations usuallyallow limited open UDP ports
for secured network. In oursetup, we use the same port for multiple
streams. Traditionalsource and destination address, and source and
destinationport based packet differentiation fails since multiple
streamsamong the sites use the same network layer flow
semantics.Therefore, to use the benefit of OpenFlow-based split
dataplane architecture, we need to ensure two properties in
packet
OpenFlow Switch
A
B
gw-‐2
C
S1A
S1A
S1A
S2A
S2A
S1AS2A D
Site-‐A
Site-‐B
Site-‐C
Site-‐D
Local Network
S1A S2A S3A
Internet
Internet
S3A
Sing
le R
ule
Inse
rtion
La
tenc
y (m
s)
Flow Table Size
(b)
0
50
100
150
200
250
300
0 200 400 600 800
OpenFlow_Overhead Linear (OpenFlow_Overhead)
Trendline f
(a)
Fig. 2. (a) Example of a 3DTI session among 4 sites, (b)
OpenFlow layer-3rule insertion latency for different sizes of flow
table.
differentiation: 1) overridden fields are not modified
anywherein the transmission path, and 2) the design does not
requireany changes in network components or OpenFlow protocol.
Overlay to flow table mapping: Next, we need to ensure thatflow
table rules are consistently installed at all the
participatingOpenFlow switches to follow the stream forwarding
actionsaccording to the overlay. However, blind mapping of
overlayto flow tables fails since it may interrupt other running
flowsin current or concurrent 3DTI sessions (e.g., via overriding
orsuperseding available flow table entries). We need to ensurethat
the flow table size is optimized in the mapping process.
To understand the impact of switch flow table size on
3DTIsession, we have conducted an isolated experiment with IBMG8264
OpenFlow switch.We measure a single rule insertionlatency for
different number of pre-installed rules into theswitch. The result
is shown in Figure 2(b). Wildcarded layer-3rules are stored in a
‘linear’ table in the TCAM space of theswitch [3]. As TCAM is
expensive and small, every wildcardedlayer-3 rule insertion
performs an internal optimization offlow tables [14], which
represents significant part of the ruleinsertion latency. This
optimization latency increases with theincrease of flow table size,
which impacts session initiationand session update latency.
Therefore, we need to ensure twoproperties while mapping the
multi-stream overlay topologyto switch flow tables: 1) modification
of flow table does notinterrupt on-going forwarding actions, and 2)
size of flow tableis as small as possible.
Seamless view change: View change introduces a new humanbehavior
in the multi-stream 3DTI environment. If the partic-ipant at Site-B
updates a view, which requests streams SA2and SA3 instead of S
A1 and S
A2 , then stream S
A1 is no longer
required by Site-B. However, if Site-A stops transmission ofSA1
to Site-B, the streaming path of S
A1 to Site-C is impacted
and therefore, should be reconfigured. Sites who are impactedby
remote view changes are called victim sites. Here, Site-Cis the
victim site due to the view change by Site-B. To ensureseamless
streaming to Site-C due to this view change, theupdate of streaming
path for SA1 to Site-C should not interferethe immersive experience
at Site-C in terms of packet loss.
Therefore, to ensure seamless view changes, the creationof new
topology and the removal of old topology for streamsshould be
performed concurrently. For example, if we updatethe path A D C in
Figure 2(a) before removing the pathA B C for SA1 , then Site-C may
get transiently over-loaded with redundant SA1 . Likewise, if we
remove the pathA B C first and then update rules to create A D C,
itintroduces temporal disconnectivity of SA1 to Site-C. What
isrequired is a concurrent update of distributed flow tables
thatensures two properties: no transient 1) bandwidth
overloading,and 2) network disconnectivity.
-
IV. OPENSESSION FRAMEWORK
OpenSession control plane contains three-layer sessionmanagement
hierarchy shown in Figure 3 and described below.
SWC
Gateway Gateway Gateway
Global Session Controller
Local Session Controller
Switch Controller
GSC
LSC LSC LSC
Internet
SWC
control path data path
Site-A Site-B Site-C
A C
B
A C
B
SRT
gSRT
CB
G
A C
B
FT
A
Fig. 3. OpenSession framework.
Global session controller: GSC represents a global controlplane,
which is an important design component for optimizedcontent
distribution [18]. GSC periodically (every few sec-onds) monitors
participating sites (such as streaming rate, 3Dconstruction time)
and their underlying infrastructure (suchas available inbound and
outbound bandwidth and end-to-end delay). During session initiation
and session update (suchas view change), GSC constructs an
optimized multi-streamoverlay content distribution topology using
global view of thesites (usually 5 to 10 [5]) and their underlying
resources. Oncethe multi-stream topology is computed, the overlay
routingrelated to each participating site is sent to the
correspondingLSC. The information is represented by a session
routing tableor SRT (§V-A1). In Figure 3, we show an example
graphcorresponding to the SRT of site-A for a multi-stream overlayG
computed at the GSC (streams from Site-A are only shown).
Local session controller: LSC is a lightweight (in terms
ofprocessing overhead) session layer. The main responsibilityof LSC
is to update session routing table ( called gSRT) atthe local
gateway (i.e., at the application data plane) usingthe SRT received
from GSC (§V-A2). Gateways use gSRT forthe data plane forwarding of
local streams. gSRT ensures thatsingle copies of local streams are
delivered out of the gateway.Figure 3 shows an example of gSRT at
the gateway of Site-A. LSC forwards SRT to local SWC to map it to
the switchflow table (FT). LSC is also responsible for monitoring
localdevices and resources, and sends them to GSC.
Switch controller: SWC directly communicates with theOpenFlow
switches connected in the local network to installforwarding
actions defined by SRT (§V-A3). An example offorwarding actions in
FT related to the SRT and gSRT ofthe previous example is shown in
Figure 3. SWC is alsoresponsible for maintaining consistency and
size optimizationin FT. We run SWC as a module of the OpenFlow
controller.
Data plane: The data plane is separated from the
managementcontrol plane and divided between the application gateway
andthe OpenFlow switch. The gateways schedule local streams
tomulticast remotely based on the connectivity graph definedby
gSRT. The OpenFlow switches multicast local and remotestreams based
on the forwarding actions defined in FT.
V. OPENSESSION PROTOCOL AND FUNCTIONALITY
A 3DTI Session is initiated by sending a session
initiationrequest to the GSC, which contains a list of sites, a
list oflocal devices (streams) at each site, and a list of desired
viewsfor all participants. Designing an efficient content
distributionoverlay that can combine different notions of quality
(e.g.,startup delay, frame rate) and user experience is an
openchallenge that is outside the current scope. Here we focuson
OpenSession protocols for: (1) mappings of multi-streamcontent
distribution topology to application and network layerdata planes,
and (2) handling of seamless changes in thedistribution topology
during session run-time.
A. Multi-stream Overlay Mapping
In this section, we will discuss, how the multi-streamoverlay is
mapped into SRT (§V-A1), gSRT (§V-A2) and finallyto OpenFlow FT
(§V-A3).
1) Overlay Topology to SRT Mapping: Once the multi-stream
overlay topology is computed, it is mapped to asession routing
table (SRT) for each participating site. Themapping of overlay to
SRT aims to associate forwardingactions with each stream. SRT
contains three fields: 1) Matchfield (SRTmatch) that contains a
stream ID, a UDP destinationport and the gateway IP address of the
stream originatingsite, 2) Forwarding action (SRTaction) that
contains a listof gateway IP addresses to forward matching streams
to, and3) Dirty bit (SRTdirty) that indicates whether an entry
hasbeen modified or not. An example of SRT computation froma
multi-stream overlay is shown in Figure 4. For clarity, weonly show
two streams originating from Site-A and Site-B. Theoverlay topology
computed by GSC is shown in Figure 4(a).Figure 4(b) shows the
corresponding SRT of Site-B.
2) SRT to gSRT Mapping: The purpose of mapping SRTto gSRT is to
define the forwarding responsibility to theapplication layer data
plane at the gateway. Each gatewaysends only single copies of the
local streams towards the localOpenFlow switch, though multiple
sites may request the samestreams. Streaming towards multiple sites
are then done fromthe OpenFlow switch via address modification
(destinationIP and MAC addresses) in the packet header. Therefore,
themapping from SRT to gSRT is done only for local streams toensure
that the gateway sends only one copy. In Figure 4(b),Site-B sends
stream SB1 to both Site-C and Site-D. However,the LSC only maps the
streaming path to Site-D in gSRT atSite-B (application data plane).
The streaming to Site-C isdone from the network layer data plane.
Figure 4(c) showsthe entries of SRT that are mapped to gSRT.
3) SRT to FT Mapping: Finally, the mapping of SRT toFT is
performed by SWC in three steps below:
Prune SRT entry: We only map dirty SRT entries. Moreover,we
prune the SRT entries (associated to the local streams),which are
already assigned to the application layer data plane(i.e., to
gSRT). For example, in Figure 4(b), the SRT entryto forward SB1
(with Match Field 192.168.1.2 : 1 : 9876) toSite-D is pruned and
not mapped to FT at Site-B. However,the SRT entry to forward SB1 to
Site-C is not pruned.
Update match field: After pruning SRT, we map SRT matchfield
(SRTmatch ) to FT match field (FTmatch). The OpenFlow
-
Match Field Forwarding Address Dirty Bit Gateway ID : Stream ID
: Destination Port
Gateway Addresses
bit
192.168.1.2: 1: 9876 192.168.10.13 192.168.1.3
1 1
192.168.1.2: 2: 9876 192.168.1.3 1 192.168.5.6: 1: 9876
192.168.1.3
192.168.10.13 1 1
192.168.5.6: 2: 9876 192.168.10.13 1
(b)
SRT of B
(a) 192.168.1.2
192.168.1.3
LSC
Gateway
LSC
Gateway
LSC
Gateway
192.168.10.13 LSC
Gateway
Site-A Site-B
Site-C
Site-D
192.168.5.6
S1A = 1 S2A = 2 S1B = 1 S2B = 2
Match Field Forwarding Address Dirty Bit Gateway ID : Stream ID
: Destination Port
Gateway Addresses
bit
192.168.1.2: 1: 9876 192.168.10.13 1 192.168.1.2: 2: 9876
192.168.1.3 1
Match Field Forwarding Address Dirty Bit Gateway ID : Stream ID
: Destination Port
Gateway Addresses
bit
192.168.1.2: 1: 9876 192.168.1.3 1 192.168.5.6: 1: 9876
192.168.1.3
192.168.10.13 1 1
192.168.5.6: 2: 9876 192.168.10.13 1
(c)
(d)
gSRT
FT
Fig. 4. (a) Multi-stream overlay topology for SA1 , SA2 , S
B1 , and S
B2 , (b) the corresponding SRT of Site-B, (c) SRT entries that
map to gSRT at Site-B
(application data plane), and (d) SRT entries that map to
OpenFlow FT serving at Site-B (network data plane). 9876 is UDP
data communication port.
protocol allows direct mapping for source IP address (gw)and
destination port (Pdst). However, the notion of applica-tion layer
stream ID (Sid) is lost in the network layer dataplane. To keep
this semantic information in the network layer,we override the
higher 5 bits of IP ToS (Type of Service)field. Overriding of IP
ToS bits is very common in Internetapplications as they are less
frequently used in Internet [7].When stream data is sent by the
gateway, the 8bit IP ToSfield of the UDP packets is set based on 5
bits of stream IDwith zeros in lower 3 bits (i.e., we do not modify
ECN bitsused for congestion control). For example, if SA1 = 1,
thecorresponding ToS field in the IP data packet is
00001000.Therefore, SRTmatch = [192.168.5.6.1 : 1 : 9876] maps
toFTmatch = [192.168.5.6.1 : 00001000 : 9876].
Update action list: In addition to forwarding the
incomingpackets to the intended destination (based on packet
header),the OpenFlow switches need to forward the same packets
toother sites (based on SRTactions) by replacing the destinationIP
and destination MAC addresses. If the destination IP isin the
remote subnet, OpenSession uses MAC address of thegateway-router.
Also, the physical port for each forwardingaction is assigned based
on the destination IP. Details areskipped due to brevity. In
summary, in addition to forwardingthe packets based on their
original headers, we add threeactions in FTaction field for each
forwarding IP x in SRTaction:1) set destination IP to x, 2) set
destination MAC addressto MACx, and 3) forward the packets to port
Portx. Here,Portx is the physical port number at the switch that
forwardsdata packets to destination x, and MACx is the MAC
addressrequired to forward data packets to destination x.
B. Seamless Session Adaptation
Session adaption (adding or dropping streams) is triggeredwhen
participants change views, or bandwidth resources at
theparticipating sites change. In this section, we only
considerview changes; other causes will naturally follow. The
result ofthe view change is route update for one or more
streams.
1) Seamless Route Update Problem: As we show in§III-B, a route
update may cause a) overloading when re-dundant streams are
transmitted to any participating site),and b) disconnectivity (when
streaming of one or morestreams becomes temporarily unavailable).
To understand thephenomena clearly, we show a route update example
withsix participating sites in Figure 5(a)-(d) for both
overloadingand disconnectivity. With frequent view changes,
interactivestreaming performance at the victim sites due to
transientoverloading and disconnectivity becomes very poor.
2) Route Update Problem Formulation: The route updateproblem can
be mapped to a constraint-based graph transfor-mation problem.
Initially, we will consider only single stream.Later (in §V-B5) we
will extend our solution for multiplestreams. Let us consider an
existing overlay graph (GSold) anda new overlay graph (GSnew)
computed at GSC after a viewchange request. We represent each graph
by a connectivitymatrix MS , where MS [i][j]=1 if Site-i forwards
stream Sto Site-j, otherwise MS [i][j]=0 (note that for the rest of
thissection we consider A as 0, B as 1 and so on while indexingthe
connectivity matrix). The transformation of graphs can beformulated
by their connectivity matrices as follows:
Graph Transformation Problem: Transform MSold (con-nectivity
matrix of GSold) to M
Snew (connectivity matrix of
GSnew) for each stream S, whereMSold 6= MSnew, so that the
intermediate states of the connectivity matrix (MSint) in
thetransformation process do not violate following two
constraints(N= number of sites): 1)
∑iM
Sint[i][j] ≤ 1, ∀0≤j≤N−1,
and 2) MSint[i][j]6=0, if MSold[i][j]=MSnew[i][j]=1
∀0≤i,j≤N−1.Constraint (1) ensures that there is no transient
overloading ofS, and (2) ensures that there is no transient
disconnectivity.
3) Route Update Solution Overview: To solve seamlessroute update
in OpenSession, we consider an additional packetheader field (η) in
the FT match entry. When we add newrules (for the purpose of
transforming MSold to M
Snew) with
a new value in η, the new rules are not matched against
theincoming streams right away, because incoming streams do
notcontain the new value of η in their packet header. In Figure
6,we provide an example of how consideration of an additionalmatch
entry (η) in FT can solve the route update problem forSA1 as shown
in Figure 5. Below we describe.
Figure 6(a) shows the initial FT rules in Site-A before theroute
update. Since Site-D does not forward SA1 , there is noFT entry at
Site-D for stream SA1 . While updating the routefrom Figure 5(a) to
Figure 5(d), we first add a new FT rule atSite-D (in Figure 6(b))
with match field entry [A, SA1 , Pdst,η′] (where η′ is the new
value of η) and an action to forwardthe matched stream to Site-C.
Even though Site-D receives SA1from Site-A, the data packets are
not forwarded to Site-C asincoming packets do not contain η′ and
are not matched withthe new rule (i.e., no violation of constraints
(1)).
To initiate the matching with new entries in FT (at Site-D), the
OpenFlow switch at the source site (at Site-A) needs toupdate η
with the new value η′ in the outgoing packet headerwhile streaming
(SA1 ). We replace the FT rule at Site-A thatforwards SA1 to Site-B
by a new FT rule with two actions: 1)forward SA1 to Site-D, and 2)
set η with η
′ in the outgoingpacket header. When this rule is inserted at
Site-A, the data
-
S1A = 1 S2A = 2
(b)
(c)
(a) (d)
Disconnectivity
Overloading
C
B
D
E
F
A
C
B
D
E
F
A
C
B
D
E
F
A C
B
D
E
F
A
Fig. 5. Problem of route update: (a) old overlay graph, (b)
disconnectivityat Site-C, (c) overloading to Site-C, and (d) new
overlay graph.
packets of SA1 towards Site-D contain η′ in the packet
header
and are redirected to Site-C from Site-D. It also terminatesthe
streaming to Site-B at the same time (Figure 6(c)). Wecan control
the instant when we want to switch streamingpaths concurrently for
a stream by modifying FT rules at thestreaming source (i.e.,
concurrently start streaming from Site-D to Site-C and stop
streaming to Site-B and Site-C). Thus,OpenSession ensures that the
victim sites are not impacteddue to the view change (or any session
adaptation) triggeredby remote sites unless the updated path
creates a large jitter,which depends on route computation
algorithms.
Among other layer-3 and layer-4 fields, we consider sourceport
(Psrc) in the UDP header as η, because changing UDPsource port for
the outgoing packets does not violate anyrouting constraints. Psrc
is monotonically increased with everyroute update and reset to 1024
(0 to 1023 are specific purposeports) when all running 3DTI
sessions terminate. Note thatgateways do not modify Psrc in the
packet header, rather theOpenFlow switch performs the replacement
on the outgoingpackets of the local streams.
If we update Psrc in the FTs only at the sites impacted by
aroute update, soon there will be different values of Psrc in
theFTs across all sites with the same source IP, UDP
destinationport and IP ToS bits, which may create inconsistency in
futureFT update. Therefore, when a route update happens for
streamS, all distributed FT rules that forward S are updated and
startmatching η′ in the Psrc match field.
Delete obsolete rules: When incoming streams are matchedagainst
the new rules, old rules becomes obsolete and aredeleted
automatically using the OpenFlow-defined timeoutprimitive. For a FT
entry, if there are no matching pack-ets for a continuous interval
defined by idle_timeout,the rule will be deleted from the switch.
We specify 30secidle_timeout. OpenFlow also uses a
hard_timeout,which removes the rule from FT after the timeout even
match-ing flows exist. OpenSession uses infinite hard_timeout.
4) OpenSession Route Update Algorithm: Summarizing theabove
discussion, 1) we need to specify a new η each time aroute update
happens, and 2) FT entries in the remote sitesneed to be updated
first before updating the FT entries at thesource site (Figure
6(a)-(c)). Below we formally present thedistributed route update
algorithm at different controller levels.
Route update at GSC: GSC is responsible for initiating theroute
update. Depending on MSnew and M
Sold, GSC classifies
Site-i into four states (a site can be in multiple states):
1) No-route Site-i not forwarding S to any site before andafter
the route update (∀j MSold[i][j]=0 ∧ MSnew[i][j]=0),
2) Drop-route Site-i drops forwarding S to any site afterthe
route update (∃j MSold[i][j]=1 ∧ MSnew[i][j]=0),
A
D
A
D to B to E
to B to E A
D
to E to C
(a) (b) (c)
Forward to B Forward to E Forward to D
[A, S1A, 9876] Match Action
Forward to C [A, S1A, 9876, η’] Match Action
Forward to E Forward to D & η=η’
[A, S1A, 9876] Match Action
Forward to C [A, S1A, 9876, η’] Match Action
Fig. 6. (a)-(c) Sequence of FT updates for a seamless route
update of SA1for the case shown in Figure 5. 9876 is the data
communication port.
3) Add-route Site-i starts receiving S from any site afterthe
route update (∃j MSold[j][i]=0 ∧ MSnew[j][i]=1), and
4) Keep-route Site-i keeps receiving S from same site afterthe
route update (∃j MSold[j][i]=1 ∧ MSnew[j][i]=1).
If a site is in no-route state, no updates in SRT and FT
arerequired and no messages are sent to the site’s LSC. If a site
isonly in drop-route state, no SRT and FT updates are required(at
non-origin sites). Obsolete entries (no match for η′) areremoved by
the timeout. If a site is in keep-route state, thoughthere is no
update required in SRT, an update in FT is stillrequired to assign
Psrc=η′ in the FT match entry (§V-B3). Aroute update request
message ΩFT is sent to the site’s LSC. Ifa site is in add-route
state, we need to update both FT and SRTto reflect the changes in
the forwarding paths at Site-i. In thiscase, GSC sends a route
update message ΩSRT FT to the site’sLSC. If a site is in multiple
states, the route update messagescorresponding to the states are
sent cumulatively to the site’sLSC. Messages ΩFT and ΩSRT FT are
sent concurrently toall sites except at the source site of S. After
all sites updatetheir tables (SRT and FT), GSC sends a route update
requestmessage to the source site. For the source site, the
selection ofroute update message is also made based on its state.
However,even the source site is at drop-route state (i.e.,
streaming to oneor more remote sites is dropped), we still need to
send ΩSRTmessage to update gSRT. Each route update message
containsnew SRT (SRTnew) with all dirty bits set to 1 (since we
needto update Psrc for all entries), and η′. To ensure the
orderingof route update requests, GSC constructs a depth first
traversal(DFT) of sites from MSnew and sends route update requests
toall sites concurrently except the last site in the order, which
isthe source site. Once route update requests are replied by
allsites, then a route update message is sent to the source site
toperform an atomic switch from MSold to M
Snew.
Route update at LSC: When ΩFT or ΩSRT FT is receivedat LSC for
remote streams, it simply forwards the messageto SWC. However, for
the local streams, LSC updates gSRTusing SRTnew using the algorithm
discussed in §V-A2 andthen forwards the message to SWC.
Route update at SWC: When SWC receives route updatemessage ΩFT
or ΩSRT FT , it maps the rules from SRTnew toFT with Psrc=η′.
Process for handling route update messagesat the source site is the
same, except Psrc is not consideredin the FT match entry field for
S, and an additional actionis added in the FT action list to
replace Psrc with η′ in theoutgoing packets of S. We modify our
mapping algorithm in§V-A3 to incorporate Psrc, however we skip it
for brevity. Toensure that the rule has been added to the FT entry,
a barriermessage is sent to the switch [22]. Reply of the barrier
messageconfirms that the previous command for rule insertion is
com-pleted successfully. Once FT entries are updated successfully,a
confirmation is sent to the GSC. Figure 7 shows an exampleof
OpenSession seamless route update process for the updateof stream
SA1 .
-
E
F
B A
D
G
C E
F
B A
D
G
C D Drops S1A
A B C D E F GA 0 1 0 0 1 0 0B 0 0 0 1 0 1 0C 0 0 0 0 0 0 0D 0 0
1 0 0 0 1E 0 0 0 0 0 0 0F 0 0 0 0 0 0 0G 0 0 0 0 0 0 0
A B C D E F GA 0 1 0 0 1 0 0B 0 0 0 0 0 1 0C 0 0 0 0 0 0 0D 0 0
0 0 0 0 0E 0 0 1 0 0 0 0F 0 0 0 0 0 0 1G 0 0 0 0 0 0 0
Transform
MoldS1A MnewS1A
GoldS1A
GnewS1A
0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 1 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 1
0 0 0 0 0 1 0 0 0 0 1 0 1 0
0 1 0 0 1 0 0 0 1 0 0 1 0 0
DFT order (i) MoldS1A[i][j]
η’ = η + 1
State Route Update Message
no-route add-route
no-route add-route keep-route
keep-route
MnewS1A[i][j]
ΩSRT_FT
ΩSRT_FT ΩSRT_FT ΩFT
N/A
N/A E
F
B A
D
G
C
GSC
E
F
B A
D
G
C ΩSR
T_FT
Ω
SRT_
FT
ΩSRT_FT
Concurrent route update Reply route update Source route
update
Ω FT
1 2 3
Order of messages
(a) (b) (c)
C
E
G
F
B
A drop-route
Fig. 7. Example of OpenSession route update process for a single
stream: (a) route update due to Site-D drops stream SA1 , (b) route
update messages andcomputed state of the sites due to the route
update, and (c) route update protocol showing the order of route
update messages.
5) Multi-stream Route Update: During a view change, ifroutes of
multiple streams are required to update in the newoverlay,
OpenSession performs source-based route update asshown in §V-B4 for
all modified streaming paths in parallel.The route update messages
(in Figure 7(d)) are sent cumu-latively for all streams. However,
the parallel route updatescan be dependent if the updates of routes
overlap at any site.For example, if Site-i drops (adds) forwarding
(receiving) ofSA1 and adds (drops) forwarding (receiving) of S
B1 in the new
overlay during session adaptation, the route updates for SA1and
SB1 become dependent as the updates overlap at Site-i. It is
challenging to guarantee seamless session adaptationwhen
route-update dependencies exist (though rare) amongstreams from
different source sites. The source-based routeupdate cannot
guarantee atomic update of routes for SA1 andSB1 at Site-i as
streams are originating from separate sources.
To ensure seamless route update at all sites,
OpenSessionconsiders a route update constraint at GSC for computing
newmulti-stream overlay: (RUC) if a site drops (adds)
forwarding(receiving) of Six, it does not add (drop) forwarding
(receiving)of Sjy in the same route update process for any x and
ywhere i6=j. Sites violating RUC may not experience
seamlessadaptation. Note that view changes do not violate RUC
sinceduring a view change i=j (i.e., streams come from the
samesite). Also, when lower priority streams are dropped due
tonetwork congestion, the overlay modification does not
usuallyviolate RUC. RUC is a natural constraint, and in most of
thecases, RUC remains valid. Details are skipped due to
brevity.
VI. EVALUATION WITH REAL 3DTI SETUP
A. Evaluation Setup
We setup 4 3DTI sites (in Figure 8(a)) in different types
ofnetworks. Site-A is in a home network, where the OpenFlowswitch
is placed next to the gateway. Site-B is in a campusnetwork, where
the OpenFlow switch is placed within thecampus network. Site-C is
in a company network, where theOpenFlow switch is placed closer to
the company’s networkedge. Site-D is in a department network, where
OpenFlowswitch is placed closer to the department’s network
edge.
Each site contains 8 video streams capturing participants3D
stereoscopic image from 450 apart and constructs a mesh-based
color-plus-depth 3D image. Instead of using physicalcameras, we
read streams from stored files, which alreadycontain the 3D video
of the participants for 1 hour session.Streams are read at the
original frame rate. Average bandwidth
C A
B
C
D
A
B D
A
B
C
D
A
B Local Streams of
Site-A
(b)
A
B
INTERNET
Office Network
Campus Network
Campus Network
Department Network
C
D
GSC
LSC SWC Gateway
Site-A Site-C
Site-B
Site-D
… …
… …
… …
… …
ccccc c
cc
3D streams
(a)
Local Streams of Site-D
Local Streams of Site-B
Local Streams of Site-C
D
C
Fig. 8. (a) 3DTI setup with 4 sites, and (b) priority-driven
multi-streamcontent distribution overlay graphs for local streams
of each site.
of each 3D stream is about 1.5 to 2.1Mbps. Each applicationnode
(site) hosts a gateway to multiplex transmission oflocal streams.
We place LSC on the same gateway host andimplement SWC as a module
of Floodlight [12] controllerrunning on a separate host at each
site. All control commandsuse TCP and data traffic uses UDP. We use
OpenFlow softwareswitches with 10GBps port capacity.
Initially, all sites request the same set of remote streams.Due
to the notion of stream priority, each view demandsonly 4 streams
from each remote participant (covering 1800space). The initial
multi-stream overlay is constructed using thetopology shown in
Figure 8(b). However, during the sessionrun-time, the overlay is
updated to meet the view changedemands. We compare the performance
of OpenSession to a“no OpenSession” case, where the gateway
performs the soledata plane functionality without using the network
support.
B. Performance Metrics
To measure the application performance, we run the same3DTI
session with and without the OpenSession control plane.No view
change is requested. Each performance value ismeasured, in
percentage, with respect to the measurementcollected without using
OpenSession (i.e., no OpenSession).
Local bandwidth: OpenSession achieves a significant reduc-tion
in bandwidth within the local network. We divide thebandwidth usage
into two parts. First, we plot how muchbandwidth we use within the
local network between thegateway and the OpenFlow switch at each
site. We noticethat (in Figure 9) Site-B, Site-C and Site-D achieve
about55% reduction in bandwidth for local streams in
OpenSession.Second, we plot how much bandwidth we use within the
local
-
0 20 40 60 80
100 No OpenSession OpenSession
0
20
40
60
80
100 No OpenSession OpenSession
0 20 40 60 80
100
No OpenSession OpenSession
0 20 40 60 80
100 No OpenSession OpenSession
Local Stream Bandwidth
Remote Stream Bandwidth
Network Delay
Processing Overhead
Local Stream Bandwidth
Remote Stream Bandwidth
Network Delay
Processing Overhead
Local Stream Bandwidth
Remote Stream Bandwidth
Network Delay
Processing Overhead
Local Stream Bandwidth
Remote Stream Bandwidth
Network Delay
Processing Overhead
7.2
Mbp
s
22.3
4 M
bps
21.3
6 m
s
15.6
%
7.36
Mbp
s
22.3
6 M
bps
19.5
3 m
s
15.6
%
15.6
%
15.6
%
22.3
2 M
bps
7.84
Mbp
s
17.2
3 m
s
8.58
Mbp
s
22.1
7Mbp
s
15.8
9 m
s
(a) Site-A
(b) Site-B
(c) Site-C
(d) Site-D
Rel
ativ
e Va
lue
(%)
Fig. 9. (a)-(d) The relative value (with respect to the
measurements without OpenSession) of performance metrics in a 3DTI
session at different sites.
network for the remote streams. The OpenSession reducesabout 35%
bandwidth for the remote streams.
Processing Load: We measure processing load of the gateway,which
includes stream receiving, scheduling and forwardingload of the
application. As shown in Figure 9, OpenSessionlowers stream
scheduling and forwarding load at the appli-cation layer data plane
by offloading part of the forwardingfunctionalities to the network
layer data plane. On average,the OpenSession improves CPU overheads
by 42% per site.
End-to-end delay: The gain in network transmission delayis
achieved in OpenSession as streams do not traverse thelocal network
for multicast-based forwarding at each multicasthop. We achieve
about 45% gain (about 8ms) in the end-to-end network delay (will be
higher for wireless end host) fortransmitting 3D frames from the
source to the destination site.
C. Impact of View Change
Views are changed according to the Zipf distribution of
20pre-selected view orientations (22.50 apart). 100 view changesare
requested from one site (Site-B) within 1 hour at equal in-terval.
Routes for the impacted streams are updated consideringconstraints
RUC (§V-B5). Valid peers (not violating RUC) toupdate streaming
paths are selected randomly. No streams aredropped after session
adaptation.
View change latency: View change latency is measured as
thedifference between the time when a view change is requestedby
Site-B and the time when Site-B receives new streamsaccording to
the view demand. In “no OpenSession” case, aftercomputing the
updated overlay at the GSC, the applicationdata plane at the
gateway is updated without consideringthe impact on victim sites.
In OpenSession, the view changelatency includes the steps shown in
Figure 7. We plot CDFof view change latency in Figure 10 with
OpenSession andwithout OpenSession. The additional overhead in view
changeby OpenSession control is very small (
-
0 0.2 0.4 0.6 0.8
1
750 1250 1750 2250 2750
OSM
Random
ViewCast
0 0.2 0.4 0.6 0.8
1
1 3 5 7 9
OSM Random ViewCast
View Change Latency (ms)
CDF
CDF
(a)
Number of Sites Update FTs in View Change (b)
Fig. 11. For different overlay computation approach in PlanetLab
setup, (a)view change latency, and (b) number of sites update flow
tables.
consider stream priority. During view changes, streamingsources
are selected randomly.
ViewCast: In ViewCast [37], initial multi-stream overlaysare
constructed considering the stream priority. During viewchanges,
the higher priority streams (among the impactedstreams) are
restored (randomly) first. Though ViewCast is adistributed
algorithm, we implement it in a centralized. way.
OSM: In OSM [5], the initial multi-stream overlays are
con-structed using evolutionary optimization to ensure a
globallyoptimized overlay considering stream priority. During
viewchanges, optimal streaming paths are selected for the
streams.
B. Impact of View Change
View change overhead: Figure 11(a) shows CDF of viewchange
latency incurred in OpenSession with three differentoverlay
construction algorithms. Though OSM causes largerview change
latency, the overhead mainly comes from the op-timization process
for the computation of the new overlay aftera view change is
requested. The average overlay computationlatencies for OSM, Random
and ViewCast are 1.3sec, 870msand 763ms, respectively. Since the
update of flow tables for aview change occurs at all sites in
parallel except at the sourcesite, the communication latency is
proportional to the tworound-trip delays between the participating
sites and the GSC.Figure 11(b) shows the CDF of number of sites
update theirflow tables over 100 view changes. Most of the cases,
70% ofthe sites are required to update their FTs. The number of
siteshere corresponds to the OpenSession message overhead duringa
view change. The message overhead of OpenSession protocolis very
small since the size of a route update message is 400B,which leads
to about 2.8KB overhead per view change.
View change resiliency: To understand the impact of viewchange
resiliency in PlanetLab setup, we run 10 3DTI sessionsamong the
PlanetLab nodes with and without OpenSession. In“no OpenSession”,
FT rules are updated in two different order-ings across the
distributed site-gateways when view changesare requested. In the
first case (case-I), we update FT rulesallowing overloading but no
disconnectivity on the streamingpath. In the second case (case-II),
we update FT rules allowingdisconnectivity, but no overloading on
the streaming path. Over1 hour experiment, we modify the number of
view changes
0
5000
10000
15000
50 100 150 200 250 300 350 400 450 500
Pack
et L
oss
Number of View Changes in 1 Hour 3DTI Session
CDF
Inbound Bandwidth to Victim Site (Mbps) (a)
(b)
0.7 0.75
0.8 0.85
0.9 0.95
1
36 36.5 37 37.5 38 38.5 39 39.5 40 40.5 41 41.5 42 42.5 43
No OpenSession: (100 View Changes/ Hour) No OpenSession: (200
View Changes/ Hour) No OpenSession: (500 View Changes/ Hour)
OpenSession: (500 View Changes/ Hour)
No OpenSession OpenSession
bursts
Fig. 12. Impact of view change frequency on (a) inbound
bandwidth to thevictim site, and (b) total number of packet loss
for all streams during 1 hour.
to get different view change frequency. We consider
Randomoverlay construction.
Figure 12(a) plots the CDF of average inbound bandwidthat the
victim sites measured in 5 seconds interval during 1 hoursession
for case-I. Without OpenSession, overloading creates asudden burst
in the inbound bandwidth of the victim sites. Thenumber of bursts
increases with the increase of view changefrequency. However, in
OpenSession, the inbound bandwidth isfairly constant even with
higher view change frequency. Figure12(b) shows the total average
number of packet losses at thevictim sites for all streams for
case-II over 1 hour session.Without OpenSession, the number of
packet losses increaseslinearly with the increase of view change
frequency due tothe frequent disconnectivity. However, OpenSession
does notcreate any packet loss at the victim sites due to view
changes.Similar resiliency can be shown for site failures.
C. OpenSession Overhead
As we implement SWC inside the Floodlight OpenFlowcontroller,
there is an extra processing overhead in the con-troller. To
measure this overhead, we use the cbench controllerbenchmarking
tool [23]. We run cbench in throughput mode,emulating 1 switch
connected to one site. We are able toprocess 225283 packet_in
events per second as comparedto 241768 in Floodlight without
OpenSession (6% overhead).
VIII. RELATED WORK
Multicast routing protocol: IP multicasting protocols
(e.g.,PIM-SM [1], MBONE [11]) do not provide any applicationlayer
programmable interface at the routers and global controlfor
run-time dynamic configurations. To physically deployPIM-SM, a
dependency across ISPs is required, which ISPs donot allow. MBONE
overcomes the ISP dependency by creatinga virtual multicast
network. However, it requires a fixedadditional backbone and does
not scale. Via OpenSession,we successfully enable quality of
service control over someparts (last miles) of the Internet
end-to-end data transmissionpaths without inter-domain control
across ISPs. OpenSessioncontrol resides only inside the local
network and only for 3DTIapplication-specific traffic.
Multimedia session control protocol: SIP is a session
layersignaling protocol [29] used for session management in
IPtelephony and VoIP services. SIP does not provide mechanisms
-
to configure data plane for streaming. Other session
protocolslike RTP [31] uses in-band control functionalities over
datato assist streaming, and RTCP [31] is out-of-band
controlprotocol for RTP. Liu et al. [18] propose to decouple data
andcontrol architecture for VoD streaming, however the focus ismore
on the server (CDN) selection. 4D TeleCast [4] providesa control
architecture for session management in 3DTI, but itonly aims for
non-immersive viewers.
Multimedia flow management: The efforts of cross-layermultimedia
flow management can be divided into three cate-gories: resource
reservation (e.g., [21], [8]), routing (e.g., [35])and flow
scheduling (e.g., [33]). Unlike RSVP, OpenSessiondoes not require
control of network routers inside the ISPsfor the feasibility
concern. OpenSession considers layer-3control over
wide-area-networking and so, MPLS [28] andother layer-2 quality
control protocols do not work. Along withdifferent overlay routing
approaches [2], various applicationlayer resource reservation and
scheduling techniques can stillbe performed within OpenSession
framework.
Application support with OpenFlow: OpenFlow is part of
theStanford University’s clean slate project. OpenFlow switchesare
controlled and modified by OpenFlow controller, enablingflexible
functions such as flow forwarding, redirection, multi-cast,
routing, and others (e.g., [20], [25], [30]). OpenFlow hasbeen used
in data centers (e.g., [13], [36], [16]) and assistingin scalable
video streaming (e.g., [10]).
IX. DISCUSSION AND CONCLUSION
OpenSession protocol adds following features in currentreal-time
collaborative applications (considering Figure 9):
Simplified data plane: The separation of data and con-trol plane
in OpenSession makes application logic simpler.Furthermore, the
partial offloading of application data planeto the network layer
reduces multi-stream management andforwarding overhead of the
application host (about 42%).
Improved application performance: The splitting of dataplane
comes with the benefits of lower bandwidth overhead(over 55% for
local streams and 35% for remote streams)within the local network
(i.e., last mile) and lower networktransmission delay (over 45%) in
multicast-based streaming.
Seamless session adaptation: OpenSession handles victimsites in
session adaptation process and seamlessly updates therunning
session without introducing any streaming interference(packet loss
or traffic burst) at the victim sites. The improve-ment is shown by
a demo video in [24].
Optimized control plane: OpenSession optimizes the flowtable
size at the OpenFlow switches. The switch controllerdoes not keep
any state, and the processing overhead at thecontroller is very
small (about 6%).
We have shown that in addition to the great potential ofSDN in
data center, it can be used very efficiently for widearea
interactive networking applications like 3DTI. OpenSes-sion
successfully leverages the network layer functionality toimprove
application performance in 3DTI.
REFERENCES[1] S. Deering et al. The PIM architecture for
wide-area multicast
routing. Transactions on Networking, 1996.
[2] K. Andreev et al. Designing overlay multicast networks for
streaming.In SPAA, 2003.
[3] M. Appelman et al. Performance analysis of OpenFlow
hardware.http://bit.ly/11SnlGt.
[4] A. Arefin et al. 4D TeleCast: towards large scale multi-site
andmulti-view dissemination of 3DTI contents. In ICDCS, 2012.
[5] A. Arefin et al. Prioritized evolutionary optimization in
open sessionmanagement for 3D tele-immersion. In MMSys, 2013.
[6] H. H. Baker et al. Understanding performance in Coliseum,
animmersive videoconferencing system. In TOMCCAP, 2005.
[7] W. Beyda et al. System and method for reinterpreting TOS
bits.USPatent7106737, 2006.
[8] E. Braden et al. Resource Reservation ProtocolRFC 2205,
1997.[9] Cisco TelePresence Video Conferencing.
http://bit.ly/12nJEPE, 2007.
[10] H. E. Egilmez et al. Scalable video streaming over
OpenFlownetworks: An optimization framework for QoS routing. In
ICIP, 2011.
[11] H. Eriksson. Mbone: the multicast backbone. Commun. ACM,
1994.[12] Floodlight. http://floodlight.openflowhub.org/.[13] N.
Handigol et al. Plug-n-server: Load balancing web traffic using
OpenFlow. In SIGCOMM, 2009.[14] B. Hedlund. On data center
scale, OpenFlow, and SDN.
http://bit.ly/gLJcIz.[15] D. Kahneman. Thinking, fast and slow.
2011.[16] E. Keller et al. Live migration of entire network (and
its hosts). In
HotNets, 2012.[17] G. Kurillo et al. Real-time 3D avatars for
tele-rehabilitation in virtual
reality. Studies in health technology and informatics, 2011.[18]
X. Liu et al. A case for a coordinated Internet video control
plane. In
SIGCOMM, 2012.[19] A. Maimone et al. Real-time volumetric 3D
capture of room-sized
scenes for telepresence. In 3DTV-CON, 2012.[20] N. McKeown et
al. OpenFlow: enabling innovation in campus
networks. In SIGCOMM CCR, 2008.[21] P. L. Montessoro. Efficient
management and packets forwarding for
multimedia flows. Network and System Management, 2012.[22]
OpenFlow. www.openflow.org.[23] OpenFlow controller benchmark.
http://bit.ly/upa5m7.[24] OpenSession Seamless Route Update.
http://bit.ly/13Oep1N.[25] M. Othman et al. Design and
implementation of application based
routing using OpenFlow. In CFI, 2010.[26] PlanetLab.
http://http://planet-lab.org/.[27] PolyCom. http://bit.ly/Vkx7PO,
2007.[28] E. Rosen et al. BGP/MPLS IP Virtual Private Networks
(VPNs) RFC
4364, 2006.[29] J. Rosenberg et al. Session initiation protocol
(RFC 3261), 2002.[30] C. Rotsos et al. OFLOPS: an open framework
for OpenFlow switch
evaluation. In PAM, 2012.[31] H. Schulzrinne et al. RTP: a
transport protocol for real-time
applications, (RFC 3550), 2003.[32] Software-Defined Networking.
http://bit.ly/LpV2lD, 2012.[33] L. Toni et al. Multi-view video
packet scheduling. arXiv:1212.4455.[34] H. Towles et al. 3D
tele-collaboration over internet2. In ITP, 2002.[35] R. Vogel et
al. Qos-based routing of multimedia streams in computer
networks. Selected Areas in Communications, 1996.[36] R. Wang et
al. Openflow-based load balancing gone wild. In HotICE,
2011.[37] Z. Yang et al. Enabling multi-party 3D tele-immersive
environments
with ViewCast. In TOMCCAP, 2010.[38] B. Yu. MyView: customizable
automatic visual space management for
multi-stream environment. PhD Thesis, 2006.[39] Z. Zhang et al.
Demo: Sword fight with smartphones. In SenSys,
2011.
