Abstract The paper proposes a resource efficient solutionfor Network Coding (NC) based congestion control consist-ing in identification around the congested links of multiplebutterfly or other low complexity NC-capable topologies byusing the Discrete Lagrange Multiplier optimization algo-rithm. The identification of the NC-capable topologies isbased on the resource management capabilities foreseen forthe network entities of the Future Internet. The congestioncontrol issue is tackled by separate encoding of appropri-ately selected groups of data flows passing through the bot-tleneck link. By optimal selection of the data flows to be en-coded, the additional network resources required by the NCoperations can be minimized. The encoding is realized byusing an XOR-based algorithm adapted for unequal bit ratedata flows, and the experimental performances are reportedhere. Due to its efficient usage of the network resources andhigh degree of scalability, the congestion control solutionproposed in this paper is suitable for large bit rate transmis-sions, like video streaming.
Keywords Congestion control · Discrete Lagrangemultiplier · Network coding · NC-capable topology · Nodearchitecture · Resource optimization · Video streaming
1 Introduction
Online video services such as IPTV, video on demand, peer-to-peer video, generate a significant part of today’s Internettraffic: around 51 % according to some studies [8], and it is
Z.I. Kiss (B) · Z.A. Polgar · M. Giurgiu · V. DobrotaCommunications Department, Technical University ofCluj-Napoca, 400027 Cluj-Napoca, Romaniae-mail: [email protected]
foreseen that the video traffic will increase to 90 % of the In-ternet traffic until the end of 2012 [8]. In order to fulfill thespecific requirements on QoS (Quality of Service) for realtime applications and to solve the associated problems ofcongestion control and resource allocation, advanced traf-fic management capabilities are imposed for the transportnetworks. Management tools supporting QoS adaptation incomplex transmission systems and for heterogeneous ser-vices were proposed in [7]. In [9] an architecture combin-ing a real-time video quality monitoring platform, on-the-fly adaptation and QoS reservation was proposed. The em-ployment of Network Coding techniques represents an al-ternative solution to these problems. Firstly introduced byAhlswede [1] in 2000, several studies were dedicated totheoretical analysis of NC [10, 14, 16] as well as to inte-gration in telecommunication networks and demanding ser-vices, like video streaming [21, 27]. In [21] it is shown thatNC techniques can eliminate the need for tight synchroniza-tion between servers in Content Delivery Networks (CDN)and can reduce the server’s storage space. It is also shownthat NC is able to reduce up to 60 % the required transmis-sion capacity, having a strong influence over network con-gestions. In [27] the potentials of NC in decreasing the de-lays and improving the error resilience in emerging CDNare described. In [17] an adaptive energy-efficient timingcontrol algorithm for NC was proposed, which is able toprovide good delay and throughput performances increasingsuccessful coding by 7 % up to 60 %.
The use of NC techniques is not the only solution forcontrolling the congestion in telecommunication networks.Multipath routing algorithms [13, 15, 20], exploiting the ex-isting path diversity in the network, as well as traffic [24]and QoS aware routing [26] algorithms are strong candidatesfor solving the congestion control issue. Other congestioncontrol algorithms, seeking to improve the fairness between
sessions sharing the same bottleneck link and to reduce theaggressiveness of TCP protocols, were proposed and ana-lyzed in [2, 23]. But, the performances of these algorithmscould be affected in directed networks or in networks havingasymmetric transfer characteristics, when finding alternativeroutes where the traffic could be re-routed can be difficult.In these situations NC represents one of the best solutionsfor dealing with the congestion control issue, besides beingpossible, by an appropriate code design, to deal with otherissues, such as error control or security [11].
Even though the advantages of the NC-based techniquesin content delivery and streaming applications are well un-derstood, implementing NC in real networks has no clearsolution. Some of the main issues are related to the iden-tification of topologies/sub-networks where NC operationscan be performed and to the design of efficient coding so-lutions. In [18] it is shown that network topology influ-ences significantly the potential benefits of NC. However,simple NC-capable topologies can be identified with rela-tively low complexity algorithms. Consequently, there areseveral studies proposing algorithms which allow discover-ing such topologies both in wired core networks and in wire-less mesh networks. In [28] the authors consider the simplestmulti-session NC, involving only two unicast flows, overdirected acyclic graphs and propose algorithms for findingbutterfly and grail topologies, which could implement NCin this particular scenario. In [12] the authors present a sub-graph detection method for discovery of the network nodeswhere NC can be implemented, the targeted networks be-ing the Wireless Mesh Networks (WMN) and the targetedtopologies being the butterfly, the extended butterfly andthe bowtie topologies. Subsequent developments of the is-sues related to the identification of NC-capable topologies inWireless Sensor Networks (WSN) can be found in [6]. In [3,5] the authors deal with the problem of identifying butterflytopologies in MPLS core networks, being proposed specificchanges of the MPLS operation modes and signaling algo-rithms for identification of the butterfly topologies and ac-tivation/deactivation of the NC operations. As a conclusion,it can be stated that a possible solution for employing NCtechniques, at least in some applications, is to identify sev-eral low complexity NC-capable topologies, each of themdealing with a smaller part of the issue to be solved, e.g.,congestion control, instead of employing a complex networkwide coding. The last one would require a large amount ofadditional network resources and processing capability aswell as complex synchronization algorithms and signalingprotocols.
The paper proposes a NC-based solution for congestioncontrol which follows the idea: instead of using a complextopology involving a large number of nodes performing NCoperations, several low complexity NC-capable topologiesare identified. Each of these topologies encodes only one
pair or a limited number of flows passing through the con-gested link, the congestion being controlled by the combinedaction of all topologies. The proposed solution has lowercomplexity and requires a smaller amount of network re-sources compared with network wide NC solutions, so it issuitable for large bit rate streaming applications, too.
Another issue considered by the paper is related to theimplementation of the NC encoding in realistic transmis-sion scenarios, because most of the theoretical studies [10,14, 16] consider NC in the unrealistic conditions of constantand equal rate flows. In our solution we cope with the un-equal rates and burstiness of the data flows to be encoded,and hence we propose a dynamic XOR-based encoding al-gorithm whose performances are analyzed.
The structure of the paper is the following: Sect. 2 in-troduces the system architecture considered. Section 3 de-scribes the proposed NC-based congestion control solu-tion. Section 4 proposes an XOR-based coding mechanismadapted to unequal bit rate transmissions. In Sect. 5 thedeveloped algorithm for identifying multiple NC-capabletopologies employed for congestion control in networkswith enhanced management capabilities is described. Thealgorithm targets to minimize the additional network re-sources required by the NC decoding. Section 6 presents theresults and discussions and Sect. 7 concludes the paper.
2 System architecture
The considered system architecture (Fig. 1) is describedshortly as follows: several multimedia content provider net-works and Internet Service Provider access networks areconnected by the same transport network, where congestionsmay occur on some links.
The border routers (BR) connecting the mentioned net-works are NC capable and the transport network includesboth NC capable routers (NCR), delimiting the links withhigh probability of congestion, and simple routers (R) with-out NC capability. The transport network has an asymmet-ric characteristic, the downstream transfer rates being largerthan the upstream transfer rates, which is usual in the case ofCDNs. In order to control the congestion, which may occurin the network, NC-capable topologies are identified aroundthe congested links or paths. These topologies include theBRs, the NCRs delimiting the congested links/paths andadditional paths between the source and destination BRs.These paths carry additional flows between the source andthe destination BRs (the NC-flows in Fig. 1), which are nec-essary for NC decoding in the destination BRs.
2.1 Node architecture
Implementation of the NC operations requires specializednetwork nodes capable to implement the coding/decoding
Network coding based resource efficient congestion control for video streaming 501
Fig. 1 CDN with NC-basedcongestion control mechanism
operations and to identify the coding topology. Meanwhile,these nodes must have cross-layer (CL) functionalities inorder to acquire the network topology and links related in-formation. Node architecture with NC capabilities and withOSI networks compatibility is proposed in [5] and extendedin [4]. This architecture represents a solution for implement-ing the NCR and BR nodes. Architecture modules necessaryto implement the CL functionalities and interfaces allowingthe bottom–up and top–down CL information exchange areproposed in [19, 22, 25].
An interesting concept proposed by the FP7-4WARDproject is that of In-Network Management (INM) [19, 22]which allow network nodes to manage their own resourcesand to interact with neighbor nodes for a better managementof global network resources. Such capabilities allow control-ling distributed network processing, like the NC operations,and it will be considered that all the transport network nodes(NCR and R), as well as the BR nodes have INM and CL ca-pabilities.
The simplified architecture proposed for the nodes imple-menting NC, based on the architecture elements presented in[4, 5, 22, 25] is given in Fig. 2. Details related to INM&CLoperations [19, 22, 25] are not included in order to make thefigure clearer.
The links, paths and topology related data are acquiredby the INM&CL module which communicates with similarmodules from the neighbor INM-capable nodes. The “NC
Fig. 2 NC and INM capable node architecture
coding/decoding and flow processing block” performs, be-sides the coding and decoding operations, the flow synchro-nization and the encapsulation of the packets carrying codeddata. This block processes the flows captured by the “Flowidentification and capture block”. The “NC control block”identifies the coding topology and activates/deactivates thecoding operations, respectively selects the coding algorithm,if it is the case. This block interacts with other similar blocks
502 Z.I. Kiss et al.
Fig. 3 The congestion control problem and the proposed NC-basedsolution
from the neighbor NC-capable nodes and with the localINM&CL module.
3 The proposed congestion control solution
A detailed formulation of the studied congestion con-trol problem is presented in Fig. 3. We consider a setof k sources, {s1, s2, . . . , sk}, and a set of k destinations,{d1, d2, . . . , dk}, each source si transmitting a data flow to asingle destination di . We denote with fi the data flow gen-erated by source si and having rate xi . All data flows passthrough the bottleneck link i1 − i2. The sources and the des-tinations are represented by NC capable BRs, while nodesi1 and i2 are NCRs located in the transport network. Thedashed lines represent si − dj , i �= j , paths which can be es-tablished in the transport network. If congestion is detectedon the i1 − i2 bottleneck link, one or several butterfly topolo-gies are identified, each topology including, besides the bot-tleneck link, a pair of source nodes, {si , sj }, a pair of des-tination nodes, {di, dj ;di-destination of si , dj -destinationof sj }, and the additional paths si − dj and sj − di . We de-note such a butterfly topology by Bi−j . Each of these topolo-gies is partially controlling the congestion on the i1 − i2
bottleneck link, the following operations being performed:
• sources si and sj send their flows fi and fj , besides theirdestinations di and dj , to nodes dj respectively di on theadditional paths established in the transport network;
• the node i1 generates the coded flow f ci−j = fi ⊕fj , andsends only this flow on the bottleneck link, decreasing thelevel of the congestion on this link;
• the node i2 sends the coded flow f ci−j to the destinationnodes di and dj ;
• the destination nodes perform the decoding and recovertheir intended flows: fi = f ci−j ⊕ fj , decoding per-formed by node di;fj = f ci−j ⊕fi , decoding performedby node dj .
The identification of the butterfly topologies and the se-lection of the flows which have to be encoded must take intoaccount the following aspects:
(a) the congestion has to be controlled on the bottlenecklink;
(b) the network resources required by the transmission ofthe additional flows (Fig. 3) have to be minimized.
The number of the identified butterfly topologies and theflows coded by each of these topologies represent a codingsolution. The computation of the coding solutions is consid-ered in Sect. 5.2.
The main advantages of the proposed congestion controlsolution are the following:
(1) low amount of additional network resources are re-quired; the maximum number of additional flows nec-essary is k (k is the number of flows passing throughthe congested link), while if all flows passing throughthe bottleneck link are coded together the number ofadditional flows required is k · (k − 1). To be possi-ble such a coding solution each source si , i = 1, . . . , k,has to establish additional paths toward all destinationnodes dj , j = 1, . . . , k, j �= i, i.e., all destination nodesexcepting node di , which may not be possible always;
(2) simple XOR based coding/decoding operations whichensure a low signaling overhead (no coding coefficientshave to be transferred between the nodes of the codingtopology) and fast coding operations (no complex Ga-lois Fields operations are required), which is importantfor fulfilling the delay requirements of the streaming ap-plications;
(3) less complex synchronization operations of the flows in-volved in the NC operations performed in each codingtopology, which reduces also the signaling overhead andthe required flow processing capabilities.
Remark: the congestion control problem considered can beextended also to the case of multicast transmissions. In thissituation the source si transmitting to a number of t desti-nations will be replaced by a number of t identical virtualsources, sil , l = 1, . . . , t , each source transmitting the sameflow to a different destination.
An example describing the presented congestion controlsolution is shown in Fig. 1. Three flows are transmitted in thenetwork: flow-A: S1–C9, flow-B: S4–C4, flow-C: S7–C3,which create congestion on the link between routers NCR_Aand NCR_B. In order to control the congestion the followingcoding solution is computed: identify a butterfly topologyincluding sources BR_A and BR_C and destinations BR_Dand BR_F, which codes flow-A and flow-C in node NCR_Aand flow-B is transmitted uncoded. Additional flows are senton the BR_A–BR_D and BR_C–BR_F paths in order to de-code the flows flow-A and flow-C in node BR_F respectively
Network coding based resource efficient congestion control for video streaming 503
Fig. 4 Congestion controltopology with three sources
in BR_D. The coded flow replaces flow-A and flow-C on theNCR_A–BR_F respectively on the NCR_A–BR_D path. It issupposed that the encoding of flow-A and flow-C is enoughto control the congestion.
The butterfly topology is very efficient from the pointof view of the additional network resources required, butit is inefficient from the point of view of the congestioncontrol capability, because only two flows are encoded. Ifthe congestion cannot be controlled only by the employ-ment of butterfly topologies, then besides these topologieswill be identified and used topologies which encode severalflows, while keeping as low as possible the amount of ad-ditional resources required. A simple example is presentedalso in Fig. 1. If the congestion cannot be controlled, inthis scenario, by encoding only flow-A and flow-C, usinga butterfly topology, it will be necessary to encode all threeflows, flow-A, flow-B and flow-C, by using a topology havingthree sources and three destinations. In Fig. 4 is presentedsuch a topology having a triplet of sources, {si , sj , sl},and a triplet of destination, {di, dj , dl;di-destination ofsi , dj -destination of sj , dl-destination of sl}. All sourcescommunicate with their destinations through the i1 − i2 bot-tleneck link and the following additional paths are instanti-ated: si − dj , si − dl , sj − di , sj − dl , sl − di and sl − dj .We denote such a topology by Bi−j−l and call it n-sourcetopology, n = 3 in this case.
Remark: a butterfly topology is equivalent with a 2-source topology.
The operations performed in this topology are the follow-ing:
• the sources send their flows fi, fj and fl , to their destina-tions through the i1 − i2 link and to the other destinationnodes of the topology on the additional paths establishedin the network;
• node i1 generates the coded flow f ci−j−l = fi ⊕fj ⊕fl ,and sends only this flow on the bottleneck link, decreasingthe level of the congestion;
• node i2 sends the coded flow f ci−j−l to destination nodesdi , dj and dl ;
• destination nodes perform the decoding and recover theirintended flows: fi = f ci−j−l ⊕ fj ⊕ fl-decoding per-formed by node di;fj = f ci−j−l ⊕fi ⊕fl-decoding per-
formed by node dj ;fl = f ci−j−l ⊕fi ⊕fj -decoding per-formed by node dl .
If it is necessary, topologies with more sources can beidentified in order to control the congestion, but the com-plexity of the solution and the amount of additional re-sources required will increase significantly.
4 The XOR-based coding operation
The coding process has to be adapted to the characteristicsof the flows (e.g., burstiness, rate) to be combined, to therequirements of the service (e.g., delay, packet error rate),and it has to be integrated in the routing/forwarding tech-niques employed in the network. It is proposed a solutionfor a XOR-based coding capable to deal with flows hav-ing different rates and packet lengths (Fig. 5). The codingis performed by the NCR (NCR_A in Fig. 1) which detectsthe congestion. The coder receives the network layer pack-ets of the n data streams to be coded and generates an outputpacket which could be:
(1) one of the network layer packets (if due to the rate dif-ferences of the source data streams combining of thesource packets is not possible at a given moment);
(2) a new network layer packet containing the XOR-ed databits and additional synchronization and signaling infor-mation.
The source BRs (BR_A, BR_B and BR_C in Fig. 1) aremodifying the data packets by inserting additional informa-tion for synchronization and signaling (Fig. 5). The codertransfers this information from the headers of the sourcepackets into the header of the coded packet. This packet hasthe destination and source address fields those of one of theoriginal data packets, while the other sets of addresses areincluded in the control header. The multicast NCR (NCR_Bin Fig. 1) generates separate coded packets which are sentto the destination BRs (BR_D, BR_E and BR_F in Fig. 1),each of the packets having the appropriate addresses. Fig-ure 5 presents the situation when the NCR_A (Fig. 1) en-codes three data packets generated by the mentioned sourcenodes (BR_A, BR_B and BR_C in Fig. 1). The data bytesof each source packet are identified by the information in-cluded in the “Sequence no.” field. It can be noticed the flex-ibility of the proposed encoding method which adapts to thecharacteristics of the source flows. The additional overheadinserted by the coding operations increases with the num-ber of the flows encoded, but for a small number of sources,i.e., 2 or 3 sources, this overhead is of 20–25 bytes and hasa reduced influence over the required bandwidth for usualRTP/UDP packet size.
The proposed coding method still has a drawback, forwhich we offer below the solution: if the source packets are
504 Z.I. Kiss et al.
Fig. 5 XOR-based codingalgorithm for variable lengthdata packets
not applied to the coder in the same moment they will beonly multiplexed on the output link, instead of being en-coded, which reduces the degree of the congestion control.In order to solve this issue, the packets of each data streamhave to be appropriately scheduled for transmission, i.e., de-layed with a time interval depending on the inter-packet de-lay distribution of the other data flows and on the applicationdelay requirements.
If there are encoded n flows and ideal scheduling is sup-posed in the coder, then the rate, xc1−n, of the coded flowf c1−n is given by:
xc1−n = max(x1, x2, . . . , xn) ≥∑n
i=1 xi
n(1)
where xi are the rates of the encoded flows.
5 Congestion control by identification of multiple lowcomplexity topologies
5.1 The proposed congestion control algorithm
Solving the congestion control problem presented in Sect. 3(Fig. 3) requires three main phases:
(1) Gathering of topology, links, paths and flows relateddata;
(2) Identification of butterfly or other types of topologies(i.e., n-source topologies) which allow to control thecongestion and fulfill some optimization criteria (e.g.,
Fig. 6 State flow diagram of the NC-based congestion control algo-rithm
minimization of the additional network resources re-quired by NC);
(3) Activation of the coding solution, if this is possible.
The algorithm proposed to solve the congestion controlproblem based on NC is described by the state diagram pre-sented in Fig. 6.
In NORMAL state the network performs legacy routingand the NCR routers check the existence of congestion onthe links/paths which could face congestions. If congestionis detected, the algorithm enters the TOPOLOGY DISCOV-
Network coding based resource efficient congestion control for video streaming 505
ERY state, where the discovery of the links/paths character-istics connecting the BRs and NCRs and of the character-istics of flows generating the congestion takes place. Thisoperation is based on the INM and CL capabilities of theBR and NCR nodes. In the COMPUTE NC SOLUTIONstate the algorithm searches for a coding solution which ful-fills the optimization criteria imposed. If such a solution isfound the algorithm enters in the CODING state, being ac-tivated the NC-based congestion control mechanism. If nocoding solution is found the algorithm returns in the NOR-MAL state.
The discovery of the topologies performing the NC op-erations is simplified and implicitly is made more practicaland scalable in the proposed approach by imposing some ofthe network nodes involved in NC. Each coding topologyincludes the gateways, i.e., the BR nodes (Fig. 1), whichroute the source flows to be encoded in each of the men-tioned topologies. In this way it is necessary to identify onlythe NCRs located in the transport network which will be in-volved in NC. The position of the NCRs can be optimizedby an appropriate design of the network.
5.2 Coding solution computation and optimization
The NC-based congestion control requires the transmissionof additional data packets as it was explained in Sect. 3. Thealgorithm proposed for finding a NC solution is pursuing theminimization of the amount of network resources requiredfor the transmission of the additional data packets. This pro-vides also a high degree of scalability to this solution, be-cause we have more chances to instantiate the paths carryingthe additional data packets. In our setup some of the sourceflows are coded in the NCR detecting the congestion, whilethe other flows are transmitted uncoded.
5.2.1 Performance evaluation of the n-source NC-capabletopologies
Generating an optimal coding solution requires the evalua-tion of the congestion control capability, resource efficiencyand complexity of the coding topologies foreseen to be em-ployed. If we consider a set {s1, s2, . . . , sk} of k sourcestransmitting through a bottleneck link and we suppose idealscheduling of the packets in the coder (see relation (1)), thefollowing relations can be written:
• Total rate, xt , on the bottleneck link:
xt =k∑
i=1
xi (2)
where xi is the rate of source si .
• Total rate, xt−NC , on the bottleneck link, if all flows arecoded together, supposing that such solution is possible(i.e., resources are available in the network allowing toeach source si to open additional paths towards all desti-nations dl , i �= l):
xt−NC = maxi=1,k
(xi) ≥ xt/k (3)
• Total additional rate, xadd−NC , required for decoding:
xadd−NC = (k − 1) ·k∑
i=1
xi (4)
• Total rate, xnt−NC , on the bottleneck link if only n-source
topologies are employed, supposing that such solution ispossible (i.e., the congestion is controlled):
xnt−NC =
m∑
j=1
maxi=1,n
(xj,i) +w∑
u=1
xu ≥ xt/n (5)
where {(xj,i , i = 1, . . . , n)}, j = 1, . . . ,m, represents the setof the rates of the source groups involved in NC, m is thenumber of groups/topologies, n is the number of sourcesfrom each group and {xu}, u = 1, . . . ,w represents the set ofthe rates of the sources not involved in NC; n · m + w = k.
• Total additional rate, xnadd−NC , required for decoding:
xnadd−NC =
m∑
j=1
(
(n − 1) ·n∑
i=1
xj,i
)
(6)
• Total number of packet level XOR operations for codingand decoding when using m topologies with n sources,Nn−m
XOR :
Nn−mXOR = Nn−m
XOR-coding + Nn−mXOR-decoding
= m · (n − 1) · (n + 1) (7)
5.2.2 Optimization of the additional network resourceswhen employing several types of n-source congestioncontrol topologies
The definition of the objective function when employingseveral types of NC-capable congestion control topologies,each with nj sources, is:
f (x) =m∑
j=1
(
(nj − 1)
nj∑
i=1
xj,i
)
(8)
where m is the number of indentified congestion controltopologies of different types, nj is the number of sourcesin topology j (nj = 2 for the butterfly topology) and xj,i isthe rate of a source having index i included in a topology
506 Z.I. Kiss et al.
having index j . If we are using only one type of topologythen nj = n,∀j .
The constraint function, h(x), is imposed by the limitedtransfer rate of the bottleneck link, xmax, and is given by thefollowing inequality:
h(x) =m∑
j=1
maxi=1,nj
(xj,i) ≤ xmax (9)
where m and nj have the same meaning as in (8).Note that the coder works according to the algorithm de-
scribed in Sect. 4 and no uncoded packets are generated atthe output of the coder due to the different rates and bursti-ness of the source flows.
After transforming the inequality constraint into anequality constraint the discrete Lagrangian [29] can be writ-ten as:
Ld(x,λ) =m∑
j=1
(
(nj − 1)
nj∑
i=1
xj,i
)
− λ · min
(m∑
j=1
maxi=1,nj
(xj,i) − xmax,0
)
(10)
where λ is the Lagrange multiplier.If the additional network resources are considered rela-
tively to the capacity of the network links/paths, the objec-tive function can be written as:
f (x) =m∑
j=1
(
(nj − 1)
nj∑
i=1
xj,i
c(xj,i)
)
(11)
where c(xj,i) is the capacity of link/path where the addi-tional data packets, associated with flow fj,i having ratexj,i , are sent to the NC decoder (the dashed lines in Fig. 3).
The constraint function imposed by the bottleneck link/path is the same as the one given by (9) and the discreteLagrangian can be written as:
Ld(x,λ) =m∑
j=1
(
(nj − 1)
nj∑
i=1
xj,i
c(xj,i)
)
− λ · min
(m∑
j=1
maxi=1,nj
(xj,i) − xmax,0
)
(12)
The capability of the Discrete Lagrange Multiplier (DLM)algorithm of finding the global minimum is strongly relatedto the definition of the “neighborhood” of the points lo-cated in the search space [29]. In our approach each pointx = (xu, . . . , xv) represents a set of sources su,...,v whichcan be combined, xu,...,v being the rates of the flows fu,...,v
generated by these sources. An appropriate definition of the
“neighborhood” allows an efficient “walk” of the algorithmthrough the search space.
Our definition of the “neighborhood” for the consid-ered optimization problems is the following: a point y =(xk, . . . , xl), representing a set of sources sk,...,l which canbe combined and generate flows fk,...,l having rates xk,...l ,is in the “neighborhood” of point x = (xu, . . . , xv), previ-ously defined, if and only if any of the following relationsis true: sb ≡ sc , where b = u, . . . , v, c = k, . . . , l. In otherwords, two points are in the same “neighborhood”, only ifthey are representing at least a common source. In order toavoid checking large neighborhoods with different sizes, themaximum size of a neighborhood is imposed at the start ofthe algorithm and it depends on the total number of sourcenodes. The usual size of the neighborhood is set to 10–20 %of the total number of sources.
5.2.3 Algorithmic description of the additional networkresources optimization method
If the congestion on the bottleneck link cannot be controlledonly by the instantiation of butterfly topologies, it is neces-sary to instantiate a number of n-source topologies, whichhave the role to decrease the rate on the bottleneck linkto a level which allows controlling the congestion by us-ing butterfly topologies or other low complexity topologies.The basic idea of the algorithm is to start with a more com-plex n-source topology and find a number of such topolo-gies (according to some criteria) which allow controlling thecongestion together with a number of e-source topologies,n > e. The search proceeds sequentially for lower complex-ity topologies until the congestion is controlled and the totalamount of additional resources required by all topologiesemployed is minimized.
The algorithm intended to compute the coding solutionin this scenario is described by the following steps:
(1) find n ∈ N , n ≥ 2, such that the congestion on the bot-tleneck link can be controlled by n-source topologies;
(2) if n = 2 go to step 7 else go to step 3;(3) find the n-source topologies which decrease the rate on
the bottleneck link to a level allowing to control the con-gestion by using (n − 1)-source topologies and fulfillsome criteria;
(4) if the (n−1)-source topologies are not necessary to con-trol the congestion go to step 8, else go to step 5;
(5) n == n − 1;(6) if n > 2 go to step 3, else go to step 7;(7) find the number of butterfly topologies which can con-
trol the congestion and minimize the additional re-sources required;
(8) Stop.
The criteria proposed to be used for the selection of then-source topologies in step 3 are the following:
Network coding based resource efficient congestion control for video streaming 507
(a) Select from the n-source topologies included in thesame neighborhood the one which requires the smallestamount of additional resources:
criterion a: minj=1,p
(n − 1) ·n∑
i=1
xj,i; p =(
r
n
)
(13)
where r is the maximum neighborhood size.(b) Select from the n-source topologies included in the
same neighborhood the one which provides the largestdecrease of the rate on the bottleneck link:
criterion b: maxj=1,p
(n∑
i=1
xj,i − maxi=1,n
(xj,i)
)
(14)
where p and r have the same meaning as in (13).
In order to decide if the congestion on the bottleneck linkcan be controlled by the n-source topologies the followingsolution is proposed: let be x1 ≤ x2 ≤ · · · ≤ xk the orderedset of the rates of the flows generated by the k sources trans-mitting through the bottleneck link; if we are using n-sourcetopologies the minimum bit rate on the bottleneck link af-ter coding, x
n,kt−NC, is given by (15), supposing that k/n ∈ N ,
additional resources are available in the network allowing toidentify any number of n-source topologies and the schedul-ing performed by the coder is an ideal one (i.e., in each mo-ment are encoded groups of n source packets).
xn,kt−NC =
(k/n)−1∑
j=0
xk−n·j (15)
The congestion on the bottleneck link having a capacity xmax
can be controlled if xn,kt−NC ≤ xmax. If this condition is ful-
filled, the congestion can be controlled by employing onlyn-source topologies or a combination of n-source and e-source topologies, n > e.
6 Results and discussions
6.1 Evaluation of the XOR-based coding algorithm
The XOR-based coding algorithm proposed in Sect. 4 wastested by encoding two video streams having the samebit rate, but characterized by different burstiness. Figure 7presents the histograms of the inter-packet delays of the twotest video streams and Fig. 8 gives the ratio between thenumber of coded, nc, and uncoded, nu, packets generatedfor several values of the waiting time inserted by the coder.Figure 8 shows that for low waiting times of the packets inthe coder the ratio between the numbers of coded and un-coded packets at the output of the coder, nc/nu, is approxi-mately 2, while for a delay of 4 ms the mentioned ratio is 5and increases significantly for larger delays.
Fig. 7 Inter-packet delay histograms of the test video streams
Fig. 8 Coded/uncoded packets ratio at the output of the coder
If we consider that the flows to be encoded have equalpacket lengths, the ratio ro/i between the output rate and thetotal input rate of the coder is given by:
ro/i = nc/nu + 1
2nc/nu + 1; lim
nu→0ro/i = 0.5 (16)
For nc/nu = 2, the ro/i ratio is 0.6, instead of 0.5, charac-teristic to the ideal scheduling in the coder (nu → 0). Fornc/nu = 5 the ro/i ratio is 0.54, close to the ideal case. Theconclusion is that a waiting time of the packets in the coderclose to the value of the inter-packet delay of the source data,corresponding to the peak of the delay histogram (Fig. 7),ensures a good congestion control on the bottleneck link. Inthe same time the value of the waiting time has to be keptrelatively small in order to fulfill the delay requirements ofthe video service.
6.2 Performance comparison of the n-source NC-capabletopologies
Based on relations (2)–(7) the n-source NC-capable conges-tion control topologies introduced in Sect. 3 are comparedfrom the point of view of effectiveness in controlling thecongestion, complexity, scalability and the amount of addi-tional network resources required in the following scenario:k identical source nodes, each generating a flow with rate
508 Z.I. Kiss et al.
Table 1 Performance comparison of the n-source NC-capable topolo-gies
n xnt−NC xn
add−NC Nn−mXOR
1 k · x 0 0
2 k · x/2 k · x 3 · k/2
3 k · x/3 2 · k · x 8 · k/3
4 k · x/4 3 · k · x 15 · k/4
k x (k − 1) · k · x (k + 1) · (k − 1)
x, one bottleneck link, ideal scheduling in the coder andk/n ∈ N , ∀n. The results obtained are presented in Table 1.The case n = 1 corresponds to the uncoded case while n = k
corresponds to the case when all sources are coded together(a single topology including all the nodes is used).
The results from Table 1 show that by employing the but-terfly topology the additional network resources are mini-mized, as well as the complexity of the NC coding/decodingoperations. This solution has the largest scalability and flexi-bility due to the reduced amount of extra resources and pro-cessing capability required. In the same time, this solutionhas the smallest congestion control capability, providing thesmallest decrease of the rate on the bottleneck link. Rel-atively to the butterfly topology an n-source topology re-quires n − 1 times more additional network resources whilethe rate on the bottleneck link is n/2 times lower. The n-source topologies require also a larger amount of processingcapability as it is shown in the last column of Table 1.
6.3 Evaluation of the discrete Lagrange multiplier basedoptimization when using one type of n-source topology
In order to test the optimization of the additional networkresources required by the NC operations a Matlab programwas implemented which solves the optimization problemin discussion by using the Discrete Lagrange Multiplier(DLM) and a brute force approach, as reference. Networktopologies having a number of k source-destination pairs, acongested link and additional links between all sources anddestinations were considered. For each number of source-destination pairs 50 individual topologies were generatedwith random distribution of the source transfer rates. Eachsource node si is connected to every destination node, ex-cept di . The transfer rate on the bottleneck link is imposed,such that it is smaller than the sum of the source transferrates.
Figure 9 presents for several values of k the logarithmof the ratio between the number of topologies checked bythe Brute Force (BF) and the Lagrange Multiplier (LM)methods, when only 2-source (butterfly) and only 3-sourcetopologies are used. The results show a significant decreaseof the number of topologies checked by the LM method,
Fig. 9 The ratio between the numbers of topologies checked by theBF and by the LM method on logarithmic scale
especially if the number of sources is large. This reducessignificantly the amount of time needed for finding a cod-ing solution and implicitly the adaptability of the congestioncontrol solution to changes in the network state.
Figure 10 presents the ratio between the number oftopologies, required to control the congestion on the bottle-neck link, found by the BF and the LM optimization meth-ods when only 2-source (butterfly) and only 3-source topolo-gies are used. The results show a decrease of the number oftopologies in the case of the LM method, when the numberof sources is larger. The LM method finds a coding solu-tion which includes fewer topologies than the solution of-fered by the BF approach, reducing the number of nodesperforming coding/decoding operations, thus the computa-tional complexity required to control the congestion.
Figure 11 presents the ratio between the additional re-sources required by the coding solutions obtained with theBF and the LM optimization methods. The results show thatwhen the LM method is used to generate the coding solutionthe additional resources required are larger with 20–50 %relatively to the case when the BF method is employed. Thiscan be explained by the definition of the neighborhood, theLM method not being capable to find the global minimumin each case. Other definition of the “neighborhood” of thepoints located in the search space (see Sect. 5.2.2) may leadto a larger probability of finding the global minimum, butin the same time it is expected an increase of the number ofoptimization steps required.
The results presented were obtained for the objectivefunction defined according (8), but similar results are ob-tained also for the objective function defined according (11).
6.4 Evaluation of the discrete Lagrange multiplier basedoptimization when using several types of n-sourcetopologies
In order to evaluate the LM based optimization methodof the additional resources when several types of n-source
Network coding based resource efficient congestion control for video streaming 509
Fig. 10 The ratio between the numbers of topologies required to con-trol the congestion found by the BF and by the LM method
Fig. 11 The ratio between the additional resources required by thecoding solutions when the BF respectively the LM method is employed
topologies have to be employed we use test network topolo-gies similar with those described in Sect. 6.3. The transferrate on the bottleneck link is adjusted in such a way to benecessary to use 4-source topologies in order to control thecongestion, i.e., the congestion cannot be controlled only by2 and 3-source topologies, and the total number of sourcenodes is fixed, k = 36.
In order to realize a more detailed analysis of the pro-cess searching for multiple n-source topologies, the algo-rithm described in Sect. 5.2.3 was adjusted to allow severalsearch mechanisms. In our scenario, the algorithm in dis-cussion will search for 4-source, 3-source and for 2-sourcetopologies, in the mentioned order—we will call this the 2–3–4 mechanism. The algorithm was adjusted to search onlyfor 4-source and 3-source topologies (we will call this the 3–4 mechanism) and to search only for 4-source and 2-sourcetopologies (we will call this algorithm the 2–4 mechanism).
Figures 12 and 13 present a comparison between thementioned algorithm variants in what concerns the opti-mization of the additional resources and the complexity ofthe search procedure, meaning the number of topologieschecked in order to generate the coding solution. Figure 12shows that there are no significant differences between the
Fig. 12 The ratio between the additional resources required by the 3–4and the 2–4 mechanisms relatively to the 2–3–4 mechanism when usingdifferent criteria to select the n-source topologies
Fig. 13 The ratio between the number of topologies checked by the3–4 and the 2–4 mechanisms relatively to the 2–3–4 mechanism whenusing different criteria to select the n-source topologies
additional resources optimization capabilities of the algo-rithm variants considered, excepting the 2–4 mechanismwhen criterion b is used to select the n-source topologies,n > 2. Figure 13 shows that the algorithm based on the 2–3–4 mechanism has to check usually more topologies thanthe other algorithm variants based on the modified searchmechanisms. This could be explained by the fact that the 2–3–4 mechanism deals with three types of topologies whenthe other search mechanisms deal with only two types oftopologies.
In Fig. 14 are presented the topologies found by the threevariants of LM based optimization algorithm considered.Both n-source selection criteria are evaluated. The figureshows that search mechanisms using criterion a generatecoding solutions with a large number of 4-source topologies.In the case of the 2–3–4 mechanism no 2-source (butterfly)topologies are found and the number of 4-source topolo-gies is large and approximately equal with the number of3-source topologies. The same is true in the case of the 3–4 mechanism using criterion a, which generates a numberof 4-source topologies slightly larger than the number of3-source topologies. In the case of the 2–4 mechanism the
510 Z.I. Kiss et al.
Fig. 14 Number of topologies found by different variants of theLM based resource optimization algorithm; xy identifies the y-sourcetopologies found when using criterion x
Fig. 15 Additional resources required by the BF and by the LMmethod when using different n-source topologies selection criteria
differences between the number of topologies found whenusing criterion a and criterion b are smaller, but in this caseas well criterion a generates more 4-source topologies com-pared to criterion b. This shows clearly that search mech-anisms based on criterion a have lower scalability. Even ifthe amount of additional resources required when using thistopology selection criterion is not larger (in average) thanthe amount of resources required when using criterion b, itmay not be possible always to generate a large number of n-source topologies with n large, not being physically possibleto establish the paths carrying the additional flows from thesources to the destinations for NC decoding. The algorithmvariant based on the 2–3–4 mechanism and using criterionb will have the largest scalability, even if the additional re-sources are not significantly lower than the additional re-sources required when using other optimization algorithmvariants, because it can use butterfly topologies which areeasier to be instantiated than more complex n-source topolo-gies and the number of 4-source topologies is the lowest.
In Fig. 15 is presented a comparison between the BF andLM based optimization in the situation considered, when wehave a mix of different topologies. The figure shows that if
criterion b is used the LM based optimization of the addi-tional resources is as good as the BF based optimization. Ifcriterion a is used to select the n-source topologies in thecase of the 2–3–4 and 3–4 mechanisms the LM based opti-mization generates coding solutions using with 25 % moreadditional resources than the coding solution obtained withthe BF optimization.
7 Conclusion
The paper proposes a congestion control solution based onthe identification of multiple NC-capable topologies hav-ing n source-destination pairs which include the congestedlinks. The algorithm identifies the most complex n-sourcetopology which has to be employed in order to control thecongestion. It searches for this type of topology and for lesscomplex e-source topologies (n > e), targeting the mini-mization of the additional network resources required by theNC operations. If possible only low complexity butterfly (2-source) topologies will be used.
The proposed congestion control solution has a large de-gree of scalability due to its basic idea: splitting the conges-tion control problem to be solved in several simpler prob-lems. The minimization of the additional network resourcesrequired contributes also significantly to the scalability ofthe proposed solution and makes it suitable for transmissionswith high bit rates, such as video streaming. The scalabilityof the solution is limited only by the INM capabilities ofthe nodes which have to discover the network, link and flowparameters.
Coding solutions can be generated easily even if the num-ber of flows is large, if the Discrete Lagrange Multiplier(DLM) based optimization is employed. It is shown that byusing our algorithm, which employs the DLM based opti-mization, coding solutions alternatives which require an ac-ceptable amount of additional network resources, comparedto the best (the most resource efficient) coding solution, canbe computed, even for a large number of flows generatingthe congestion.
The paper proposes a node architecture that integratesINM, CL and flow processing capabilities. This architec-ture offers support for running algorithms performing dis-covery of NC-capable topologies and for implementation ofNC and related synchronization and resource managementoperations. Also, a simple and flexible XOR-based codingalgorithm, capable to code data flows with unequal rates,has been implemented and the results analyzed, being shownthat complex scheduling algorithms are not required in thecoder.
Acknowledgements This paper was partially supported by theproject “Doctoral studies in engineering sciences for developing theknowledge based society-SIDOC” contract no. POSDRU/88/1.5/S/60078, project co-funded from European Social Fund through Sec-torial Operational Program Human Resources 2007-2013.
Network coding based resource efficient congestion control for video streaming 511
References
1. Ahlswede, R., Cai, N., Li, S.-Y. R., & Yeung, R. W. (2000). Net-work information flow. IEEE Transactions on Information Theory,46(4), 1204–1216.
2. Altman, E., Avrachenkov, K. E., & Prabhu, B. J. (2005). Fair-ness in MIMD congestion control algorithms. Telecommunica-tions Systems, 30(4), 387–415.
3. Biermann, T., et al. (2009). Description of generic pathmechanism. Deliverable 5.2.0. FP7-4WARD architecture anddesign for the future Internet. http://www.4ward-project.eu/index.php?s=file_download&id=38. Accessed 15 June 2011.
4. Biermann, T., Polgar, Z. A., & Karl, H. (2008). Cooperation andcoding framework. In Proceedings of IEEE ICC (pp. 1–5).
5. Biermann, T., Schwabe, A., & Karl, H. (2009). Creating butterfliesin the core—a network coding extension for MPLS/RSVP-TE. InLecture notes in computer science: Vol. 5550. Proceedings of theIFIP-TC6 networking conference (pp. 883–894).
6. Boning, F. J., Helberg, A. S. J., & Grobler, M. J. (2010). A compar-ison of wireless node topologies for network coding using practi-cal path-loss models. In Proceedings of IEEE ICN 2010 (pp. 145–150).
7. Bordetsky, A., Brown, K., & Christianson, L. (2001). A feedbackcontrol model for managing quality of service in multimedia com-munications. Telecommunications Systems, 17(3), 349–371.
8. Cisco Systems (2008). Approaching the zettabyte era. WhitePaper. http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11-481374.pdf. Access-ed 15 July 2011.
9. Develder, C., Lambert, P., Van Lancker, W., Moens, S., et al.(2012). Delivering scalable video with QoS to the home. Telecom-munications Systems, 49(1), 129–148.
10. Fragouli, C., & Soljanin, E. (2006). Information flow decomposi-tion for network coding. IEEE Transactions on Information The-ory, 52(3), 829–848.
11. Fragouli, C., & Soljanin, E. (2007). Network coding applications.Foundations and Trends in Networking, 2(2), 135–269.
12. Grobler, M. J., Helber, A. S. J., & Terblanche, S. E. (2010). Op-timal subgraph detection to identify opportunities for the applica-tion of deterministic network coding. In Proceedings of SATNAC2010.
13. He, J., Suchara, M., Bresler, M., Chiang, M., & Rexfort, J. (2007).Rethinking Internet traffic management: from multiple decompo-sition to a practical approach. In Proceedings of CoNEXT 2007.
14. Ho, T., Medard, M., Koetter, R., Karger, D. R., Effros, M., Jun, S.,& Leong, B. (2006). A random linear network coding approachto multicast. IEEE Transactions on Information Theory, 52(10),4413–4430.
15. Kandula, S., Katabi, D., Davie, B., & Charnie, A. (2005). Walkingthe tightrope: responsive yet stable traffic engineering. In Proceed-ings of ACM SIGCOMM 2005.
16. Koetter, R., & Medard, M. (2003). An algebraic approach tonetwork coding. IEEE/ACM Transactions on Networking, 11(5),782–795.
17. Li, H., Chan, E., & Chen, G. (2010). AEETC—adaptive energy-efficient timing control in wireless networks with network coding.Telecommunications Systems, 45(4), 289–301.
18. Lima, L., Ferreira, D., & Barros, J. (2011, online first). Topologymatters in network coding. Telecommunications Systems.
19. Martin, D., Zitterbart, M., et al. (2011). Prototype implementa-tions. In L. Correia, H. Abramowicz, M. Johnsson, & K. Wunstel(Eds.), Architecture and design for the future Internet—4WARDproject (pp. 271–275). New York: Springer.
20. Musariello, L., & Perino, D. (2009). Evaluating the performanceof multi-path routing and congestion control in presence of net-work resource management. In Proceedings of ICUMT 2009.
21. Nguyen, K., Nguyen, T., & Cheung, S. (2010). Video streamingwith network coding. Journal of Signal Processing Systems, 59(3),319–333.
22. Nunzi, G., Dudkowski, D., et al. (2009). In-network man-agement concept. Deliverable 4.2. FP7-4WARD architectureand design for the future Internet. http://www.4ward-project.eu/index.php?s=file_download&id=37. Accessed 15 June 2011.
23. Oothongsap, P., Viniotis, Y., & Vouk, M. (2006). Theoretical anal-ysis of the SABUL congestion control algorithm. Telecommunica-tions Systems, 31(2–3), 115–139.
24. Qazi, I. A., & Znati, T. (2011). On the design of load factor basedcongestion control protocols for next-generation networks. Inter-national Journal of Computer and Telecommunications Network-ing, 55(1), 45–60.
25. Rus, A. B., Barabas, M., Boanea, G., et al. (2010). Cross-layerQoS and its application in congestion control. In Proceedings ofIEEE LANMAN 2010 (pp. 1–6).
26. Rus, A. B., Dobrota, V., Vedinas, A., Boanea, G., & Barabas, M.(2010). Modified Dijkstra’s algorithm with cross-layer QoS. ActaTechnica Napocensis Electronics and Telecommunications, 51(3),75–80.
27. Thomos, N., & Frossard, P. (2009). Network coding: from theoryto media streaming. Journal of Communications, 4(9), 628–639.
28. Wang, C.-C., & Shroff, N. B. (2007). Beyond the butterfly—agraph-theoretic characterization of the feasibility of network cod-ing with two simple unicast sessions. In Proceedings of IEEE ISIT2007 (pp. 121–125).
29. Wu, Z. (2000). The theory and applications of discrete constrainedoptimization using lagrange multipliers. Ph.D. thesis, Univ. of Illi-nois at Urbana-Champaign.
Zsuzsanna Ilona Kiss receivedDipl.Eng. degree, M.Sc. degree inTelecommunications Engineeringfrom the Technical University ofCluj-Napoca in 2008 and 2010, re-spectively. Currently she is a Ph.D.student at the above mentioned uni-versity. Her research interest in-volves cooperative communicationsand network coding.
Zsolt Alfred Polgar receivedDipl.Eng. degree, M.Sc. and Ph.D.degrees in Telecommunications En-gineering from the Technical Uni-versity of Cluj-Napoca in 1995,1996 and 2002, respectively. Since1996 he is with the CommunicationDepartment of Technical Universityof Cluj-Napoca, where currently heis Associate Professor. His researchinterests involve error correctingcodes, wireless networks, networkcoding and cooperative communi-cations.
Mircea Giurgiu received M.Sc. andPhD degrees in Telecommunica-tions Engineering from the Tech-nical University of Cluj-Napoca,Romania in 1990, and 1996 re-spectively. He is Professor withthe Communication Department ofTechnical University of Cluj-Napoca since 2006. His researchinterests include engineering meth-ods for automatic speech recogni-tion, text-to-speech synthesis, digi-tal content management, and web-based applications for education.
Virgil Dobrota holds Dipl.Eng.in Telecommunications (1987) andPh.D. in Electronics and Telecom-munications (1995) from Techni-cal University of Cluj-Napoca. Heis currently professor at TU Cluj-Napoca and Head of Communica-tions Department, teaching switch-ing and routing systems, Internetprotocols and unified communica-tions. Professor Dobrota was in-volved in RACE-MAGIC, INCO-COPERNICUS 1529, ACTSAC235, COST 290, FP7-4WARD.Member of IEEE Communications
Society, ACM-SIGCOMM, he served as TPC Co-Chair at IEEELANMAN 2007 and General Co-Chair at IEEE LANMAN 2008.
