Computer Networks 57 (2013) 3067–3080

Contents lists available at ScienceDirect

Computer Networks

journal homepage: www.elsevier .com/ locate/comnet

An optimal deployable bandwidth aggregation system q

1389-1286/$ - see front matter � 2013 Elsevier B.V. All rights reserved.http://dx.doi.org/10.1016/j.comnet.2013.07.012

q An earlier version of this paper has appeared in the proceedings of the5th IFIP International Conference on New Technologies, Mobility andSecurity (NTMS) 2012 [1].⇑ Corresponding author. Tel.: +1 (404) 645-4232.

E-mail addresses: karim.habak@ejust.edu.eg (K. Habak), mousta-fa.youssef@ejust.edu.eg (M. Youssef), kharras@cs.cmu.edu (K.A. Harras).

Karim Habak a,⇑, Moustafa Youssef a,b, Khaled A. Harras c

a Wireless Research Center, Egypt-Japan University of Science and Technology (E-JUST), Alexandria, Egyptb Alexandria University, Alexandria, Egyptc Computer Science Department, School of Computer Science, Carnegie Mellon University Qatar, Qatar

a r t i c l e i n f o

Article history:Received 12 November 2012Received in revised form 6 April 2013Accepted 18 July 2013Available online 30 July 2013

Keywords:Bandwidth aggregationMultiple network interfacesThroughputOptimizationMultihoming

a b s t r a c t

The explosive increase in data demand coupled with the rapid deployment of various wire-less access technologies have led to the increase of number of multi-homed or multi-inter-face enabled devices. Fully exploiting these interfaces has motivated researchers topropose numerous solutions that aggregate their available bandwidths to increase overallthroughput and satisfy the end-user’s growing data demand. These solutions, however, donot utilize their interfaces to the maximum without network support, and more impor-tantly, have faced a steep deployment barrier. In this paper, we propose an optimal deploy-able bandwidth aggregation system (DBAS) for multi-interface enabled devices. We presentthe DBAS architecture that does not introduce any intermediate hardware, modify currentoperating systems, modify socket implementations, nor require changes to current appli-cations or legacy servers. The DBAS architecture is designed to automatically estimatethe characteristics of applications and dynamically schedule various connections and/orpackets to different interfaces. We also formulate our optimal scheduler as a mixed integerprogramming problem yielding an efficient solution. We evaluate DBAS via implementa-tion on the Windows OS and further verify our results with simulations on NS2. Our eval-uation shows that, with current Internet characteristics, DBAS reaches the throughputupper bound with no modifications to legacy servers. It also highlights the significantenhancements in the response time introduced by DBAS, which directly enhances the userexperience.

� 2013 Elsevier B.V. All rights reserved.

1. Introduction

The Federal Communications Commission (FCC) recentnotice on the data tsunami problem predicts a 25–50� in-crease in mobile data traffic by the year 2015 [2,3]. Fortu-nately, the widespread deployment of various wirelesstechnologies coupled with the increase of multi-interfaceenabled devices are providing users with many alterna-tives for sending and receiving data. Simultaneously lever-

aging these interfaces by potentially aggregating theirbandwidths can lead to higher throughput, improvedend-user experience, efficient resource utilization and,more importantly, a solution for the world-wide data tsu-nami problem.

Unfortunately, current devices and operating systemsdo not exploit the true potential of these interfaces asthey allow only the usage of one interface at a time.Researchers have addressed the multi-interface band-width aggregation problem over the years with solutionsand techniques implemented at different layers of theprotocol stack with a large focus on solutions at the trans-port and network layers [4–19]. These solutions, however,have faced a steep deployment barrier and do not utilizethese interfaces to their maximum without networksupport.

3068 K. Habak et al. / Computer Networks 57 (2013) 3067–3080

In order to have successful bandwidth aggregation sys-tems for multi-interfaced devices, it is inevitable for thesesystems to be: (1) Easily deployable without requiringchanges to legacy servers, applications, or the addition ofnew hardware such as proxy servers and routers, (2) Opti-mally exploiting all the available network interfaces totheir maximum, and (3) Able to leverage the availableapplications, interfaces, and traffic characteristics, for moreeffective scheduling decision making.

We therefore present an Optimal Deployable BandwidthAggregation System (DBAS) for multi-interface enabled de-vices. Our system is based on a middleware that lies belowthe application layer, requiring no changes to either the OSkernel or the applications. One of the core functionalities ofthis middleware is to schedule different connections and/or packets to different interfaces. We propose connection-oriented and packet-oriented scheduling techniques thataim to maximize the overall system throughput. We alsoformulate an optimal scheduling technique that allowsthe user to achieve the maximum throughput. We showthat this is a mixed integer programming problem thatcan be efficiently solved due to its special structure. Fur-thermore, DBAS leverages the resume functionality com-mon in many protocols [20] to enable packet-levelscheduling with current legacy servers to achieve higherperformance gains. Finally, as our system is graduallyadopted, DBAS leverages the existence of any DBAS-en-abled server for further performance gains.

We evaluate our system via implementation. To bothtest the scale of our system and validate our implementa-tion results, we conduct further evaluation via simulationson NS2 [21]. Currently, our DBAS prototype is deployedusing a standard MS Windows installation, highlighting itsdeployability and ease of use. We use the overall systemthroughput as well as the different applications responsetimes as our main evaluation metrics. We compare the re-sults with the current operating system’s approach as wellas other baseline schedulers. Our results show that DBASsignificantly increases the overall system throughput andminimizes the applications response time, which enhancesthe user experience. In addition, with no changes to thecurrent Internet architecture, DBAS reaches the throughputupper-bound.

The remainder of this paper is organized as follows. Wefirst present a motivating scenario for DBAS in Section 2.We present the DBAS architecture and components in Sec-tion 3. Section 4 discusses our different scheduling tech-niques and formulates our optimal scheduler. Details ofour DBAS implementation is presented in Section 5. Weevaluate our scheduling techniques in Section 6. Section 7discusses the related work and how DBAS compares tothem. Finally, Section 8 concludes the paper and providesdirections for future work.

2. Motivating scenario

Most mobile devices today are equipped with multipleheterogeneous network interfaces. For example, John’smobile device is equipped with Wi-Fi, WiMax and 3G.When John is sitting in a mall, waiting for a train at the sta-

tion, or having a meal, he typically watches YouTube vid-eos, listens to podcasts, uses Facebook and Twitter to gethis social network feeds, and opens CNN and BBC to readthe news. He connects his mobile device to available Wi-Fi hotspots while being connected to his 3G and WiMaxnetworks.

Unfortunately, his current operating system assigns allhis connections to Wi-Fi only. Consequently, John has towait until the YouTube video is buffered in order to watchit continuously without disruption; meanwhile otherapplications are slowly retrieving their content over thesame interface. With the high contention for Wi-Fi fromother users, the available bandwidth is degraded and Johndisconnects his device from Wi-Fi to utilize his high band-width 3G or WiMax connections. Although, this increaseshis throughput, the available bandwidth is not sufficientto smoothly retrieve the content, in addition to the addedoverhead of restarting all his connections as well. How-ever, his YouTube video will continue buffering from thepoint it reached when John was using Wi-Fi since YouTubeservers support connection resume.

From this scenario, we observe that John’s needs can besatisfied by concurrently utilizing his available networkinterfaces. Since John has multiple connections runningconcurrently on his device, these connections can bescheduled across the different interfaces in order to en-hance his experience. Such scheduler should take the net-work interface characteristics, bandwidth heterogeneity,and different application characteristics into account whenscheduling different connections to the available inter-faces. Furthermore, the scheduler should be able to utilizethe fact that some servers support the resume functional-ity in order to seamlessly migrate connections assignedto an interface that got disconnected to another. Thescheduler can also leverage this resume functionality toschedule the data at a finer granularity in order to increaseJohn’s overall throughput.

3. A deployable bandwidth aggregation system

In this section, we provide an overview of the DBASarchitecture and components which are depicted inFig. 1. We consider a client device, equipped with multiplenetwork interfaces, and connected to the Internet. Eachinterface has its own parameters in terms of bandwidth, la-tency, and loss ratio. The device is running multiple appli-cations with different communication characteristics. In itsdefault connection-oriented mode, DBAS schedules differentconnections to the interfaces such that a connection can beassigned to only one of the available interfaces. Once as-signed to an interface, all the packets of this connectionutilize the same interface. DBAS, therefore, achieves band-width aggregation without requiring any support from orchanges to the legacy servers. On the other hand, if theend server happens to be DBAS-enabled or the applicationlayer protocol used at the other end supports connectionresume, our system leverages this fact to further enhancethe performance by switching to a packet-oriented mode,where each packet or group of packets can be scheduled

Fig. 1. DBAS system architecture.

K. Habak et al. / Computer Networks 57 (2013) 3067–3080 3069

independently on a different interface. DBAS is composedof the following components:

3.1. Mode detection module

The purpose of this module is to detect whether theend point of the connection supports DBAS or not in orderto enable the optional packet-oriented mode. This moduleis implemented as a service that runs on a specific portreserved for DBAS. When a client tries to establish anew connection, it first attempts to connect to this port.If successful, this indicates that DBAS is supported at theend point and hence the packet-oriented mode can beused. As a result, DBAS on the client side will then openmultiple connections to the destination and distributethe application data across these interfaces. If DBAS isnot supported on the server, the client reverts to the con-nection-oriented mode except if the connection isresumable.

3.2. Resume module

This module is utilized when communicating with leg-acy servers. The purpose of this module is to enable packet-oriented scheduling even if the server is not DBAS-enabled.To detect whether a particular server supports the resumefunctionality or not, DBAS depends on a web service thatmaintains a list of protocols that support the resume func-

tionality. DBAS caches the list of protocols returned fromthe web service and periodically checks for updates. Eachprotocol is represented by a template that uniquely identi-fies the protocol, e.g. its port number, as well as how tocheck with the end server that it supports the resume func-tionality, e.g. checking for the ‘‘Accept-Ranges’’ header op-tion in HTTP. The DBAS Resume Module uses the protocolinformation check with the server if it supports the resumefunctionality or not and enables the optional packet-ori-ented mode accordingly.

The resume module is implemented as an in-deviceproxy responsible for identifying the resumable connec-tions, scheduling the different resumable sub-connec-tions across the different device interfaces, and closingthese sub-connections once they finish. To minimizethe latency and buffer size the application needs to waitfor the in-order delivery of data, the module uses twoapproaches: (1) it divides the connection into fixedlength units, where a unit with an earlier offset fromthe beginning of the connection is retrieved in parallelover the multiple interfaces before the next unit isstarted. Each interface is assigned a portion of the unitto retrieve based on wights decided by the scheduler.(2) It orders the interfaces in a descending order accord-ing to their scheduling weight and starts the sub-connec-tion with the larger weight first. This way, larger amountof data will arrive in order from the beginning of theconnection.

3070 K. Habak et al. / Computer Networks 57 (2013) 3067–3080

3.3. Application characteristics estimator

To be fully deployable, DBAS should not require anychanges to existing applications. Knowing the applicationcharacteristics, however, enables us to fully utilize theavailable interfaces and make better scheduling decisionsregardless of the mode of operation. Our approach is toautomatically estimate the characteristics of the applica-tions based on their behavior. These characteristics arestored in a database for keeping track of the applicationsbehavior. This functionality is the responsibility of theapplication characteristics estimation module that utilizesboth qualitative and quantitative measures.

3.3.1. Qualitative measuresSome features can be used to characterize the behavior

of an application. For example, the process name can beused to determine whether the process is realtime, e.g.Skype, or bandwidth intensive, e.g. an FTP client. Similarly,specific ports reserved by the application can also be usedto characterize application behavior.

3.3.2. Quantitative measuresThe module also estimates the average connection data

demand in bytes of any given application. After a connec-tion is terminated, the module updates the estimated val-ues of connection data demand (Cdemand) as:

CdemandðiÞ ¼ ð1� qÞCdemandði� 1Þ þ qTCdemandðiÞ ð1Þ

where TCdemand(i) is the number of bytes transmitted bythe ith connection of this application which has just fin-ished, Cdemand(i) is the new estimate of the connection datademand, and q is a smoothing coefficient, taken equal to0.125,1 to evaluate the equation efficiently. We note thatthe granularity of estimation can be rendered more finegrained at the expense of increased complexity and lowerscalability.

3.4. Interface characteristics estimator

This module is responsible for estimating the character-istics of each network interface. In particular, it estimatesthe available bandwidth and packet error rate at eachinterface. This estimation depends on the following twomodes of operation.

� Legacy server communication mode: In this mode,this module periodically connects and communicatesto various geometrically dispersed servers to estimatethe uplink and downlink available bandwidth for eachinterface. These estimates are then combined with thestatistics collected during the normal data transferoperation. The estimates are sufficient as the bandwidthbottlenecks typically exist at the client’s end not theserver’s. This assumption is realistic because serversacross the Internet are typically connected to highbandwidth links designed to scale with many clientrequests.

1 This way, the estimate can be obtained by an efficient shift operation.

� DBAS-enabled server communication mode: In thismode, both ends of the connection implement DBAS.This can be leveraged to obtain more accurate route-specific estimates. In this case, the module interactswith the destination to better estimate interface con-nection parameters.

3.5. Received data reordering module

This module is utilized in the packet-oriented mode,whether it is for communication with a DBAS-enabled ser-ver or a legacy server that supports the resume operation.It is responsible for the in-order data delivery to the appli-cations and has two modes of operation:

� Legacy server communication mode: Packets re-ordering can occur while communicating with a legacyserver due to the different sub-connections enabled onthe different interfaces by using the resume operation.In this case, this module needs to reorder the incomingdata units and chuncks from the different interfacesbefore passing them to the application layer at thereceiver end. A data chunk represents a group of pack-ets from the application’s data unit. This reordering atthe destination is enabled by the sender adding a DBASheader that contains a chunkId. When an interface isdown, unacknowledged chunks can then be re-sentover other interfaces, showing the effect of connectionmigration.� DBAS-enabled server communication mode: In this

case, the packet-oriented mode is the default mode. Eachchunk of data is sent in a packet similar to the legacyserver case.

3.6. User interface module

This module is responsible for obtaining the user’s pref-erences and interface usage policies. The user can config-ure this module to enforce some interface selectioncriteria. For example, the user may wish to assign specificapplications (e.g. realtime applications) to specific inter-faces (e.g. wired).

3.7. Scheduler

The DBAS scheduler uses the application and interfacecharacteristics estimators to schedule the connections,and/or packets, to different interfaces. Since this compo-nent is the core of DBAS, we cover it in detail in the follow-ing section.

3.8. Operational snapshot

Fig. 2 shows how the different components are put to-gether in order to build our system. In summary, our sys-tem has three main working steps:

Step 1: All the sensing modules gives their sensed dataand estimates to the schedule in order to make itaware of the available set of interfaces and their

Fig. 2. Detailed architecture components interactions.

K. Habak et al. / Computer Networks 57 (2013) 3067–3080 3071

parameters, the application characteristics, theuser requirements as well as the scheduling modeof operation.

Step 2: The scheduler determines the assignment policyto the different interfaces that maximizes theoverall system throughput and gives the resumemodule the packet distribution weights in orderto schedule connection resumes accordingly.

Step 3: The scheduler assigns interfaces to connectionsand distributes the packet-oriented load acrossthe different interfaces. Meanwhile, the resumemodule sends resume requests with the prede-fined weights.

Fig. 3 shows a flowchart that describes the decisionmaking process. It illustrates the differences in the sched-uling process between packet-oriented and the connec-tion-oriented modes. It also shows the difference inprocessing between DBAS-enabled based and resumable-connection based packet-oriented scheduling. In particular,in case of having resumable connections, the packet distri-bution responsibility moves from the scheduler to the re-sume module. Hence, the scheduler would only informthe resume module about its selected packet distributionweights.

4. Optimal scheduler

In this section, we formulate the optimal schedulingproblem. We start by describing our system model fol-lowed by the problem formulation. Afterwards, we presentour optimal scheduling algorithm for different cases.

4.1. System model

Table 1 summarizes the system parameters and nota-tion. We assume a mobile device with m interfaces eachwith an available bandwidth bj. The device is running aset of applications that share these interfaces. Our schedul-ing unit is a connection, regardless of its applicationsource. The application, however, may be used to charac-

terize the connection in terms of QoS by the ApplicationCharacteristics Estimation Module (Section 3.3). We referto a standard network connection as a stream to avoidconfusion with the scheduling unit. Our scheduler’s goalis to assign streams to interfaces in order to maximizethe overall system throughput (T ). Scheduling decisionsare taken when a new stream (number of streams activein the system is n, including the new stream) is requestedfrom an application.

The Mode detection module (Section 3.1) and theResuming module (Section 3.2) then determine whetherthe operation mode is connection-oriented (Sn = 1), or pack-et-oriented (Sn = 0) if the other end is DBAS-enabled or theconnection is resumable respectively. If the stream is con-nection-oriented, the scheduler’s goal is to determine towhich interface the stream should be assigned (setsxnj = 1 for only one interface j). Afterwards, the otherstreams running in packet-oriented mode, have the packetdistribution (wj) over the interfaces recalculated. On theother hand, if the new stream is packet-oriented, then per-centage of packets to be assigned to each interface, i.e.interfaces relative packet load (wj), should be re-calculatedbased on the current system load (L).

4.2. Optimal scheduling

Here, we describe our objective function and systemconstraints. The decision variables are: (1) If Sj = 1, whichinterface to assign the new stream n to (variable xnj) and(2) the new values for wj, "j: 1 6 j 6m.

4.2.1. Objective functionThe overall objective of the scheduler is to maximize

the overall system throughput (T ).

Maximize T ¼ L

maxj

Djð2Þ

where Dj is the time needed for interface j to finish all itsload (connection and packet based). Since L is constant,the objective function becomes:

Fig. 3. Decision making process.

3072 K. Habak et al. / Computer Networks 57 (2013) 3067–3080

Minimize maxj

Dj

Minimize maxj

Pni¼1 Li 1� Sið Þwj� �

þPn

i¼1 LiS ixij� �

bj

� �

4.2.2. ConstraintsThe following constraints must be satisfied:Integral Association: If the new stream is connection-

oriented, it should be assigned to only one interface:

Xm

j¼1

xnj þ ð1� SnÞ ¼ 1 ð3Þ

Note that when Sn = 0, xnj = 0, "j, which is the case whenthe new stream is determined to be packet-oriented bythe Mode detection module.

Packet Load Distribution: For packet-oriented streams,their total load should be distributed over all interfaces:

Xm

j¼1

wj ¼ 1 ð4Þ

Variable Ranges: The constraints for the range of thedecision variables are:

wj P 0; 1 6 j 6 m ð5Þ

xnj 2 f0;1g; 1 6 j 6 m ð6Þ

4.3. Scheduling algorithm

The DBAS optimal scheduler aims to maximize the over-all system throughput by minimizing the time needed fortransmitting the full system load. In general, this problemis a mixed 0–1 Integer Programming problem as the xij

variables are binary and the other variables are real. How-ever, it has a special structure that allows for an efficientsolution summarized in Algorithm 1. In particular, we havetwo cases: if the new stream that triggered the schedulingdecisions is packet-oriented (Sn = 0) and if it is connection-oriented (Sn = 1). In the packet-oriented case, xnj = 0"j. Theproblem becomes a standard linear programming problem,which can be solved efficiently [22,23] to determine thedifferent values of wj.

In the connection-oriented case, we need to determinethe binary variables "jxnj such that only one of them equals1 and others are 0. Since the load of packet-oriented con-nections can be re-distributed on different interfaces, the

K. Habak et al. / Computer Networks 57 (2013) 3067–3080 3073

optimal solution can be reached by assigning the new con-nection-oriented stream to the interface that minimizes thetime needed to finish the entire connection-oriented load,ignoring the packet-oriented load. This is equivalent to set-ting xnj = 1 for the interface that has the minimum

LnþPn�1

i¼1LiSixijð Þ

bj

� �. We then re-distribute the packet-oriented

load on the interfaces based on the updated load solving alinear program.

Algorithm 1. DBAS’s optimal scheduling algorithm

Input: Type of new stream (Sn), type of currentstreams (Si), their assignment to interfaces (xij),remaining load for each stream (Li) and interfacescharacteristics (bj).

Output: Assignment of the new stream to an interface(xnj,xnj = 0 if packet-based) and new weights fordistributing packet-based streams over eachinterface (wj).

Initialization: jmin ¼ 1; Tmin ¼LnþPn�1

i¼1LiSixijð Þ

b1

� �.

if the new stream type is connection-orientedforj = 2, . . . , m

T ¼ LnþPn�1

i¼1LiSixijð Þ

bj

� �

if T < Tmin

Tmin = Tjmin = j

end ifend forxnjmin

¼ 1;8k–jminxnk ¼ 0

else"j: xnj = 0

end ifcalculate "j: xj using Simplex Method

5. Implementation

To verify the deployability of DBAS, we implement it onthe Microsoft Windows Operating System; currently, wehave clients for Windows 7, Vista, and XP. We choose theWindows platform to further demonstrate the deployabili-

Table 1List of symbols used.

Symbol Description

T The overall system throughputL The current system loadLi The current system load for stream iSi Determines whether stream i is con. based (1) or packet-

based (0)bj The effective bandwidth of interface jDj The time needed for interface j to finish its loadxij For connection-oriented streams, equals 1 if stream i is

assignedto interface j, equals 0 otherwise

wj The ratio of packets assigned to interface jn Number of active streams including the new requestm Number of interfaces

ty of DBAS even on closed-source operating systems. In thissection, we briefly discuss our implementation of DBASspecifically highlighting our DBAS middleware and moni-toring application. Both software modules are installedusing a standard Windows executable.

5.1. DBAS middleware

We implement the DBAS middleware as a Layered Ser-vice Provider (LSP) [24], which is installed as part of theTCP/IP protocol stack in the Windows OS. This middlewareimplementation uses the same concept used in imple-menting firewalls and network proxies in order to controltraffic flows. The procedure starts when the application,which aims to connect to the Internet, uses the Winsock2 API. Windows will dynamically link it to the Winsock 2library which contains the implementation of all the Win-sock 2 functions. This library sends its requests to the ser-vice provider which later forwards it to the base protocol,such as TCP/IP. Our DBAS LSP intercepts the Winsock 2API requests and either schedules the connection to its se-lected interface or distributes data across the different net-work interfaces based on the mode of operation. Inaddition, it performs the functionality of the mode detec-tion, application characteristic estimation, interface char-acteristic estimation, and received data reorderingmodules described in Section 3.

5.2. Monitoring application

The monitoring application, of which a snapshot isshown in Fig. 4, represents the user interface module thatcaptures the user’s preferences and interface usage poli-cies, and further monitors DBAS behavior. This module ismainly for testing purposes, where it allows the user to se-lect one of the scheduling techniques which DBAS offers. Italso provides the ability to perform manual assignment ofcertain applications to certain interfaces. Finally, this mod-ule allows users to monitors DBAS internal data structuresestimated values by interfacing with the DBAS middleware.

6. Performance evaluation

In this section we evaluate the performance of DBAS viaimplementation. Results have been validated using simula-tion on NS2 [21]. We start by describing our experimentalsetup followed by the results.

Table 2Experiments parameters.

Parameter Range Nominal value

L1 Bandwidth (Mbps) 6 6L2 Bandwidth (Mbps) 6 6IF1 Bandwidth (Mbps) 0.25–2 1IF2 Bandwidth (Mbps) 0.7 0.7IF3 Bandwidth (Mbps) 2 2bsmall (Connections/s) 13 13blarge (Connections/s) 0–5 1ksmall (KB) 22.38 22.38klarge (MB) 0.02238–2 0.285a (%) 0, 40, 100 0–100c (%) 0 0–100

Fig. 4. DBAS monitoring application.

3074 K. Habak et al. / Computer Networks 57 (2013) 3067–3080

6.1. Experimental setup

Table 2 lists the main parameters we employed in ourevaluation. We built a testbed that consists of fournodes: a legacy server, a DBAS-enabled server, a client,and an intermediate traffic shaper node. Both serversare the connection destinations. The intermediate nodeis a device running the NIST-NET [25] network emulatorto emulate the varying network characteristics of eachinterface. The client is the connection generator enabledwith multiple network interfaces. On the client, we rundifferent applications that vary in terms of the numberof connections per second they open (b), the averageconnection data demand (k) and the application layerprotocol used. The client is connected to the intermedi-ate node through three different interfaces IF1, IF2 andIF3. The servers are connected to the intermediate nodeusing high bandwidth links L1 and L2. We note that thecombined bandwidth of IF1, IF2 and IF3 is less than theavailable bandwidth at any server in order to test thetrue impact of varying the interface characteristics andscheduling strategies. We define c 2 [0,100] as the per-centage of connections that have DBAS-enabled serversas their destinations. When c = 0 all the connections havelegacy servers as their destinations. However whenc = 100 all the connections have the DBAS enabled serv-ers as their destinations.

On the client, we choose to evaluate DBAS using twoclasses of applications: small load, and large load. Thesmall load applications represent typical web browsingapplications and have an average connection data demandof ksmall = 22.38 KB [26]. On the other hand the large loadapplications represent the P2P and FTP like applicationsthat have an average connection data demand ofklarge = 0.285 MB [26]. The connection establishment ratefollows a poisson process with mean (b) connections persecond. bsmall, and blarge are varied in our experiments to

evaluate the system performance over different applica-tion mixes. We define a 2 [0,100] as the percentage of con-nections that can be resumed. When a = 0 all the streamscannot be resumed. However when c = 100 all the streamsare resumable. Finally, each experiment represents theaverage of at least 15 runs with 90% confidence interval.

We use the following two metrics:

Average Throughput: Is the average amount ofdata transmitted per sec-ond. This Metric measuresthe overall performance ofthe system and its abilityto utilize the available net-work interfaces.

Application Response Time: It is the average data trans-mission delay needed for aconnection from this appli-cation to finish its datademand. This metric mea-sures DBAS enhancementsto the end user’s qualityof experience.

The system parameters are the percentage of resumableconnections (a), percentage of connections with DBAS-en-abled servers (c), interface characteristics, applicationworkloads, connection heterogeneity and resuming mod-ule division unit. We compare the DBAS optimal schedulerto three baseline schedulers:

� Throughput Upper Bound: This scheduler representsthe theoretically maximum achievable throughput,which we use as an upper bound.� Round Robin: Assigns streams (packets) to the destina-

tion legacy (DBAS-enabled) server on a rotating basis toeach network interface.

K. Habak et al. / Computer Networks 57 (2013) 3067–3080 3075

� Weighted Round Robin: Similar to the RR schedulerbut weights each interface by its estimated bandwidth;interfaces with larger bandwidths have proportionallymore packets or connections scheduled to them.

6.2. Results

6.2.1. Streams with DBAS-enabled servers (c) vs Resumablestreams (a)

As discussed in Section 3, DBAS works with both legacyand DBAS-enabled servers and it leverages the DBAS en-abled server in order to enhance performance.

Fig. 5 shows the effect of changing the percentage ofstreams established with DBAS-enabled servers (c) on theperformance of DBAS for different values of a representingthe percentage of resumable streams. Based on the figure,we share the following observations: (1) When c and a arelow, most of the streams are connection-oriented, render-ing the scheduling decision coarse grained; once thestream is assigned to an interface, all its packets have togo through this interface until termination, which reducesthe scheduling optimality. (2) When c = 0 and a = 0 DBAScan still enhance the throughput by 150% as compared tothe current OSs just based on the connection-orientedmode. (3) For a = 0%, the system reaches its throughputupper bound when we have only 25% of the streams con-

0

1

2

3

4

5

6

Thro

ughp

ut (M

bps)

0 10 20 30 40 50 60 70 80 90 100Streams with DBAS-Enabled Servers (%)

IF1

IF2

IF3 (Current OS)

XPUT BoundDBAS (α = 40%)DBAS (α = 20%)DBAS (α = 10%)DBAS (α = 0%)

Res

pons

e Ti

me

of L

arge

Con

nect

ions

(Sec

)

0

1

2

3

4

5

6

7

8

9

10 20 30 40 50 60 70 80 90 100Streams with DBAS-Enabled Servers (%)

DBAS (α = 0%)DBAS (α = 10%)DBAS (α = 20%)DBAS (α = 40%)

DBAS (α = 100%)

0

Fig. 5. Impact of changing the percentage of s

nected to DBAS-enabled servers. (4) With the increase ofa the need for DBAS-enabled servers decreases and the sys-tem reaches the throughput upper bound when a = 40%.This ratio of servers that support the resume operation istypical in the current Internet situation [20], without anyDBAS-enabled server. (5) Although the throughput reachesits upper bound when a = 40% without any DBAS-enabledserver, the importance of the existence of DBAS-enabledservers comes in minimizing the response time of the dif-ferent applications and enhancing the end user experience.(6) The response time of the different applications reachesits optimal value only when c = 100% because of two mainreasons; (i) The connections assigned in the connection-ori-ented mode utilize only one interface which makes themless responsive compared to the ones assigned in the pack-et-oriented mode and (ii) Although the resumable connec-tions are scheduled in packet-oriented mode, theirperformance, in terms of response time, is lower than theones connected to DBAS-Enabled servers due to the con-nection resumption and management overhead. For theremainder of this paper, we fix c at 0%, which representsa worst-case scenario.

6.2.2. Impact of interface heterogeneityIn this experiment, we change the bandwidth of IF1

from 0.25 Mbps to 2 Mbps while fixing the bandwidths of

2.8

3

3.2

3.4

3.6

3.8

Thro

ughp

ut (M

bps)

0

0.5

1

1.5

2

Res

pons

e Ti

me

of S

mal

l Con

nect

ions

(Sec

)

10 20 30Streams with DBAS-Enabled Servers (%)

XPUT BoundDBAS (α = 40%)DBAS (α = 20%)DBAS (α = 10%)

DBAS (α = 0%)

0

10 20 30 40 50 60 70 80 90 100Streams with DBAS-Enabled Servers (%)

DBAS (α = 0%)DBAS (α = 10%)DBAS (α = 20%)DBAS (α = 40%)

DBAS (α = 100%)

0

treams with DBAS-enabled servers (c).

3076 K. Habak et al. / Computer Networks 57 (2013) 3067–3080

the other two interfaces at 0.7 Mbps and 2 Mbps. Here wecompare DBAS to the round robin and weighted round ro-bin schedulers.

Fig. 6 shows the impact of changing the bandwidth of thefirst interface on the system performance. When the band-width of IF1 is low, using only IF3 outperforms the round ro-bin scheduler. The main reason for this is that round robindoes not take the interface characteristics into accountwhile scheduling the connections across these differentinterfaces. Therefore, it assigns the same amount of datato each network interface. Hence, the low bandwidth inter-face becomes the bottleneck. We also notice that using DBASwith a = 0 (all the connections are not resumable) outper-forms the weighted round robin scheduler since our modeltakes the application characteristics into account whilescheduling the connections. Although in this experimentall the connections have legacy servers as their destination,DBAS with a = 40% was able to utilize all the interfaces totheir maximum as it exploits the resumable connectionsas an opportunity for packet-oriented scheduling.

Since IF3 has the maximum bandwidth over the othertwo interfaces, we remove them in the rest of the paperfor clarity.

6.2.3. Impact of application heterogeneity (bLarge)Fig. 7(a) shows the impact of changing the system work-

load on overall system throughput. For this experiment,

0

1

2

3

4

5

6

0 0.25 0.5 0.75 1 1.25 1.5 1.75 2

Thro

ughp

ut (M

bps)

IF1 available bandwidth (Mbps)

IF1IF2

IF3 (Current OS)

DBAS (α = 40%)DBAS (α = 0%)

Weighted Round RobinRound Robin

0

5

10

15

20

25

0 0.25 0.5 0.75 1

Res

pons

e Ti

me

of S

mal

l Con

nect

ions

(Sec

)

IF1 available ba

IF1

IF3 (Current OS)

RWeighted R

DBDBA

Fig. 6. Impact of interfa

we fix bsmall at 13 connections/s while varying blarge. Thisfigure shows that DBAS with a = 100% is not affected bythe application heterogeneity because all the streams arescheduled in packet-oriented mode. On the other hand,DBAS with a = 0% running in connection-oriented mode isnot sensitive to the application heterogeneity because ittakes the application characteristics into account whilescheduling. Weighted round robin achieved a throughputclose to DBAS when bLarge = 0 because all the runningstreams are generated from the same application havingthe same characteristics. However, once bLarge exceeds 0,weighted round robin’s performance degrades because itdoes not take the application characteristics into account.

Fig. 7(b) and (c) show the effect of changing the systemworkload on the average response time of the differentapplications. The figures show that with the increase ofthe system load the contention increases on the networkinterfaces and the response time of the different applica-tions increases as well. DBAS is the least affected schedulerdue to its adaptivity to application loads and interfacescharacteristics.

6.2.4. Impact of connection heterogeneity (kLarge)Fig. 8 depicts the effect of skewing the connection

length distribution, i.e. fixing kSmall and increasing kLarge.The figure shows that as the connection lengths becomemore heterogenous, the throughput of connection-oriented

0

10

20

30

40

50

60

70

80

0 0.25 0.5 0.75 1 1.25 1.5 1.75 2

Res

pons

e Ti

me

of L

arge

Con

nect

ions

(Sec

)

IF1 available bandwidth (Mbps)

IF1

IF2

IF3 (Current OS)

Round RobinWeighted Round Robin

DBAS (α = 0%)DBAS (α = 40%)

1.25 1.5 1.75 2ndwidth (Mbps)

IF2

ound Robinound Robin

AS (α = 0%)S (α = 40%)

ce heterogeneity.

0 0 1 2 3 4 5

βLarge

1

2

3

4

5Th

roug

hput

(Mbp

s)

IF3 (Current OS)

DBAS (α = 100%)DBAS (α = 0%)

Weighted Round RobinRound Robin

0 0 1 2 3 4 5

Res

pons

e Ti

me

of L

arge

Con

nect

ions

(Sec

)

βLarge

10

20

30

40

50

60

70

80 Round RobinIF3 (Current OS)Weighted Round RobinDBAS (α = 0%)DBAS (α = 40%)

0

5

10

15

20

0 1 2 3 4 5

Res

pons

e Ti

me

of S

mal

l Con

nect

ions

(Sec

)

βLarge

Round RobinIF3 (Current OS)Weighted Round RobinDBAS (α = 0%)DBAS (α = 40%)

Fig. 7. Impact of application heterogeneity (bLarge).

K. Habak et al. / Computer Networks 57 (2013) 3067–3080 3077

scheduler (a = 0%) suffers from the coarse grained schedul-ing granularity and deviates from the its optimality. Thepacket-oriented variant (a = 100%), is not affected by theheterogeneity as its scheduling granularity is packet-based. We notice that this skew further downgrades theperformance of weighted round robin because it does nottake the application heterogeneity into account and over-loads the high bandwidth interfaces. This is also the reasonbehind the decrease in benefit of using the weighted roundrobin as compared to the round robin scheduler as kLarge in-creases. On the other hand, the performance time of theapplications increases for all the schedulers because ofthe increase of the system load and the contention. DBASis the least affected by this increase.

6.2.5. Impact of resuming module division unitFig. 9 shows the impact of changing the division unit of

the Resuming Module on performance. When a = 0%, theperformance is not affected by the division unit becauseall streams are assigned in connection-oriented mode. How-ever, when a = 100%, small division unit values lead to poorperformance and in some cases is lower than using only oninterface due to the overhead per packet. As the divisionunit increases, the throughput increases till it reaches thethroughput upper bound. Increasing the division unit fur-ther decreases the throughput as it starts suffering fromcoarse-grained granularity scheduling. However, it stillachieves higher throughput compared to a = 0%

6.3. Discussion

Our results show that simultaneously leveraging multi-ple interfaces significantly enhances the system perfor-mance. packet-oriented scheduling, due to its fine-grainedscheduling, can reach the throughput upper bound. con-nection-oriented schedulers can achieve high performancegains compared to current operating system withoutrequiring any changes to legacy servers. DBAS opportunis-tically combines connection-oriented scheduling and pack-et-oriented scheduling to obtain the best attainableperformance. DBAS is able to achieve the throughput upperbound with only 25% of the servers being DBAS-enabled orwith 40% of the legacy servers support the resume opera-tion, which is typical in today’s Internet.

Our results also highlighted that even though DBAS fo-cuses on maximizing the overall system throughput, it sig-nificantly minimizes the different applications responsetime. This minimization directly affects the user makingher requests and connections more responsive andenhancing her experience.

The results also demonstrate the importance of inter-face and application characteristics estimation in multi-interface schedulers. The round robin scheduler does nottake interface characteristics into account in their deci-sions, which renders their performance worse than the sin-gle interface case under some scenarios. Similarly, it isimportant to take the application characteristics into ac-

0

1

2

3

4

5

0 0.5 1 1.5 2

Thro

ughp

ut (M

bps)

λLarge (MB)

IF3 (Current OS)

DBAS (α = 100%)DBAS (α = 0%)

Weighted Round RobinRound Robin

0

50

100

150

200

250

300

350

0 0.5 1 1.5 2

Res

pons

e Ti

me

of L

arge

Con

nect

ions

(Sec

)

λLarge (MB)

Round RobinIF3 (Current OS)Weighted Round RobinDBAS (α = 0%)DBAS (α = 40%)

0

5

10

15

20

25

30

0 0.5 1 1.5 2

Res

pons

e Ti

me

of S

mal

l Con

nect

ions

(Sec

)

λLarge (MB)

Round RobinIF3 (Current OS)Weighted Round RobinDBAS (α = 0%)DBAS (α = 40%)

Fig. 8. Impact of connection heterogeneity (kLarge).

0

1

2

3

4

5

6

1 10 100 1000

Thro

ughp

ut (M

bps)

Division Unit (KB)

IF1

IF2

IF3 (Current OS)

XPUT BoundDBAS (α = 100%)

DBAS (α = 0%)

Fig. 9. Impact of changing the division unit.

3078 K. Habak et al. / Computer Networks 57 (2013) 3067–3080

count while scheduling. If not, as in the weighted round ro-bin scheduler, a large connection can be assigned to a slowinterface degrading the system performance.

Even though DBAS can provide signficant performancegains using legacy servers with resume functionality, usingDBAS-enabled servers for packet-oriented scheduling hasthe following advantages: (1) It minimizes the overheadof sending resume requests; (2) It opens a single connec-tion per interface the lives until the end of the main stream

while using the resuming module has an added cost ofopening a new connection for each resume request; (3) Itenables the underlying TCP to increase its congestion win-dow and consequently maximizes the interface usage. (4)It is not sensitive to division units; and finally (5) It de-creases the connections response time as it does not intro-duce resumption related overhead and delay.

We observe that the DBAS architecture makes eachDBAS-enabled client independent from each other. This en-ables DBAS to be highly scalable in terms of the number ofclients. The impact of increasing the number of DBAS-en-abled nodes in the same network is sharing the commonbandwidth, which will be captured by the interface charac-teristics estimation module. The extra required capacityhas to be provisioned for by the service provider. We haveconfirmed these observations via simulations.

Finally, We highlight that we built DBAS over TCP be-cause it is the most challenging. However, DBAS can simi-larly deal with UDP traffic, which most of the audio andvideo streaming applications utilize, as one more opportu-nity for packet-oriented scheduling that enables furtherenhancements to the overall throughput. The main chal-lenge to this assertion is how we can effectively supportUDP while missing a crucial parameters in our modelwhich is the estimated connection length. This challengecan be handled by the fact that UDP is typically not used

K. Habak et al. / Computer Networks 57 (2013) 3067–3080 3079

alone for audio and video applications. It is used along withother protocols like RTP and RTSP which maintain a con-nection-like association between the two end points. Usingthese protocols along with UDP has recently changed thecharacteristics of UDP to look and act more like TCP [27],as compared to the typical constant bit-rate and burstyconnectionless communication it used to be. Consequently,our model is easily applicable to modern utilization of UDPin these cases.

7. Related work

There have been many approaches that address themultiple interface bandwidth aggregation problem overthe years. These techniques are implemented at differentlayers of the protocol stack. Application layer solutionstypically assume that the applications themselves areaware of the existing network interfaces and take theresponsibility of utilizing them for their needs [13]. In par-ticular, the burden of monitoring the interfaces and param-eters estimation lie on the applications. Although, thisapproach enables the applications to utilize the interfacesin order to get exactly what they need, it misses optimalitybecause the applications are unaware of the load intro-duced by other applications. Socket level solutions, onthe other hand, modify the kernel socket handling func-tions to enable existing applications to use multiple inter-faces [13,14]. Such solutions achieve high performancegains because they distribute the data across the differentinterfaces in packet granularity. However, it requireschanges to the legacy servers in order to support thesenew sockets. In addition [14], requires feedback from theapplications about their performance, and hence is notbackwards compatible with previous versions of theapplications.

Many bandwidth aggregation techniques, however, nat-urally lie in the transport layer [4–8,28,9–11,29,12]. Thesesolutions replace TCP with mechanisms and protocols thathandle multiple interfaces. They can achieve the highestperformance gains because they schedule the data acrossthe interfaces in packet-level granularity without addingeither extra headers for reordering purposes or redun-dancy in reliability support. Unfortunately, such tech-niques require changes to the client operating system,legacy servers, and/or applications; and hence have a hugedeployment barrier.

Network layer approaches update the network layer tohide the variation in interfaces from the running TCP pro-tocol [15–17]. Chebrolu et al. [15] require having a proxyserver that communicates with the client and is aware ofthe client’s multiple interfaces. Others implement theirsystem at both connection-ends, which makes theirdeployment rely on updating the legacy servers [16]. Inaddition, they require real-time estimation/knowledgeabout the running TCP protocol status and estimatedparameters, which adds to their overhead. On the otherhand, MAR [17] requires having a special router as wellas an optional proxy server. The fact that modern operatingsystems, such as Windows, MAC OS, and Linux; still allowusers to use only one of the available interfaces, even if

multiple of them are connected to the Internet, attest thatall current proposals for bandwidth aggregation face asteep deployment barrier.

Finally, even though our recent work in bandwidthaggregation is deployable [30,19,18] and energy-aware[19,18], they do not utilize the available interfaces to theirmaximum. G-DBAS [18] and DNIS [30] work in connection-oriented mode only. DNIS only focuses on increasing thesystem throughput but G-DBAS added a focus on the en-ergy awareness. OPERETTA [19] is not able to utilize theinterfaces to their maximum in case of non-OPERETTA en-abled servers. Furthermore, all solutions have also not ta-ken advantage of the server resume capability.

8. Conclusion and future work

In this paper, we have presented a practical system forbandwidth aggregation on multi-interface enabled devices.We have proposed DBAS, an optimal deployable bandwidthaggregation system for devices with multiple networkinterfaces. We have presented the components of our sys-tem, demonstrated its deployability, formulated our sched-uling problem and developed an optimal scheduleraccordingly, compared it to other state-of-the-art solu-tions, and evaluated its performance via implementation.

Our results showed that DBAS significantly enhancesthe system’s performance as well as the user’s quality ofexperience. They highlighted that when c = 0 and a = 0DBAS can still enhance the throughput by 150% as com-pared to the current OSs, just based on the connection-ori-ented mode. DBAS can also reach the throughput upper-bound under the conditions of the current Internet.

We are currently expanding our system in differentdirections. First, developing DBAS schedulers that canadapt to other system metrics such as cost and trust. Sec-ond, creating adaptive scheduling strategies sensitive touser profiles and real-time needs. Finally, properly docu-menting the code to make it public for the researchcommunity.

References

[1] K. Habak, M. Youssef, K. Harras, DBAS: a deployable bandwidthaggregation system, in: International Conference on NewTechnologies, Mobility and Security (NTMS’12), 2012.

[2] The Network Paradox Part I: Mobile Data Demand by The Numbers,<http://connectedplanetonline.com/4gparadox/Mobile-data-by-the-numbers-1005/>.

[3] Fccs National Broadband Plan. <http://www.broadband.gov/>.[4] L. Magalhaes, R. Kravets, Transport Level Mechanisms for Bandwidth

Aggregation on Mobile Hosts, Urbana 51 61801.[5] M. Zhang, J. Lai, A. Krishnamurthy, L. Peterson, R. Wang, A transport

layer approach for improving end-to-end performance androbustness using redundant paths, in: USENIX Annual TechnicalConference, 2004.

[6] H. Hsieh, R. Sivakumar. A transport layer approach for achievingaggregate bandwidths on multi-homed mobile hosts. WirelessNetworks 11.1–2 (2005) 99–114.

[7] Y. Dong, D. Wang, N. Pissinou, J. Wang, Multi-path load balancing intransport layer, in: Next Generation Internet Networks, 3rd EuroNGIConference on, IEEE, 2007, pp. 135–142.

[8] A. Argyriou, V. Madisetti, Bandwidth aggregation with SCTP, in:GLOBECOM’04, vol. 7, 2004, pp. 3716–3721.

[9] K. Kim, Y. Zhu, R. Sivakumar, H. Hsieh, A receiver-centric transportprotocol for mobile hosts with heterogeneous wireless interfaces,Wireless Networks 11 (4) (2005) 363–382.

3080 K. Habak et al. / Computer Networks 57 (2013) 3067–3080

[10] D. Sarkar, A concurrent multipath TCP and its markov model, in:Communications, 2006. ICC’06. IEEE International Conference on,vol. 2, IEEE, 2006, pp. 615–620.

[11] J. Iyengar, P. Amer, R. Stewart, Concurrent multipath transfer usingSCTP multihoming over independent end-to-end paths, IEEE/ACMTransactions on Networking 14 (5) (2006) 951–964.

[12] L. Magalhaes, R. Kravets, MMTP: multimedia multiplexing transportprotocol, ACM SIGCOMM Computer Communication Review 31 (2supplement) (2001) 220–243.

[13] H. Sakakibara, M. Saito, H. Tokuda, Design and implementation of asocket-level bandwidth aggregation mechanism for wirelessnetworks, in: Proceedings of the 2nd Annual InternationalWorkshop on Wireless Internet, ACM, 2006, p. 11.

[14] B. Higgins, A. Reda, T. Alperovich, J. Flinn, T. Giuli, B. Noble, D.Watson, Intentional networking: opportunistic exploitation ofmobile network diversity, in: ACM Mobicom’10, 2010, pp. 73–84.

[15] K. Chebrolu, B. Raman, R. Rao. A network layer approach to enableTCP over multiple interfaces. Wireless Networks 11.5 (2005) 637–650.

[16] D. Phatak, T. Goff, A novel mechanism for data streaming acrossmultiple IP links for improving throughput and reliability in mobileenvironments, in: INFOCOM 2002. Twenty-First Annual JointConference of the IEEE Computer and Communications Societies.Proceedings. IEEE, vol. 2, IEEE, 2002, pp. 773–781.

[17] P. Rodriguez, R. Chakravorty, J. Chesterfield, I. Pratt, S. Banerjee, Mar:A commuter router infrastructure for the mobile internet, in: ACMMobiSys’04, 2004, pp. 230.

[18] K. Habak, M. Youssef, K. Harras, G-DBAS: a green and deployablebandwidth aggregation system, in: Wireless Communications andNetworking Conference, 2012. WCNC2012. 2012 IEEE, IEEE, 2012.

[19] K. Habak, K. Harras, M. Youssef, Operetta: an optimal energyefficient bandwidth aggregation system, in: 2012 9th Annual IEEECommunications Society Conference on Sensor, Mesh and Ad HocCommunications and Networks (SECON), IEEE, 2012, pp. 121–129.

[20] A. Rahmati, C. Shepard, C. Tossell, A. Nicoara, L. Zhong, P. Kortum, J.Singh, Seamless Flow Migration on Smartphones Without NetworkSupport. arXiv:1012.3071.

[21] S.F.S. McCanne, NS Network Simulator. <http://www.w3schools.com/browsers/browsers_os.asp>.

[22] J. Nelder, R. Mead, A simplex method for function minimization, TheComputer Journal 7 (4) (1965) 308–313.

[23] R.M. Karp, George Dantzig’s impact on the theory of computation,Discrete Optimization 5 (2) (2008) 174–185.

[24] W. Hua, J. Ohlund, B. Butterklee. Unraveling the mysteries of writinga Winsock 2 layered service provider. Microsoft Systems Journal 30(1999) 47.

[25] M. Carson, D. Santay, Nist net-a Linux-based network emulationtool, Computer Communication Review 33 (3) (2003) 111–126.

[26] J. Erman, A. Mahanti, M. Arlitt, C. Williamson, Identifying anddiscriminating between web and peer-to-peer traffic in the networkcore, in: ACM WWW’07, 2007.

[27] C. Lee, D. Lee, S. Moon, Unmasking the growing UDP traffic in acampus network, in: Passive and Active Measurement: 13thInternational Conference, Pam 2012, Vienna, Austria, March 12–14,2012, Proceedings, vol. 7192, Springer-Verlag New YorkIncorporated, 2012, pp. 1.

[28] A. Abd El Al, T. Saadawi, M. Lee, LS-SCTP: a bandwidth aggregationtechnique for stream control transmission protocol* 1, ComputerCommunications 27 (10) (2004) 1012–1024.

[29] J. Anand, D. Sarkar, Architecture, implementation, and evaluation ofa concurrent multi-path real-time transport control protocol, in:Military Communications Conference, 2007. MILCOM 2007. IEEE,IEEE, 2008, pp. 1–7.

[30] A. Saeed, K. Habak, M. Fouad, M. Youssef, DNIS: a middleware fordynamic multiple network interfaces scheduling, ACM SIGMOBILE

Mobile Computing and Communications Review 14 (2) (2010) 16–18.

Karim Habak is a Research Assistant atEgypt-Japan University of Science and Tech-nology. He received his M.Sc. degree in Com-puter Science and Engineering from Egypt-Japan University of Science and Technology(E-JUST), Egypt in 2012 and a .B.Sc. in Com-puter and Systems Engineering from Alexan-dria University, Egypt in 2010. His researchinterests include bandwidth aggregation,cognitive radio networks, sensor networks,and pattern recognition. Karim is the recipientof the Best Computing and Information

Technology Research Program of the Year award of the 2012 Third QatarFoundation Annual Research Forum.

Moustafa Youssef is an Associate Professor atAlexandria University and Egypt-Japan Uni-versity of Science and Technology (E-JUST),Egypt. He received his Ph.D. degree in com-puter science from University of Maryland,USA in 2004 and a B.Sc. and M.Sc. in computerscience from Alexandria University, Egypt in1997 and 1999 respectively. His researchinterests include mobile wireless networks,computing, location determination technolo-gies, pervasive computing, and networksecurity. He has eight issued and pending

patents. He is an area editor of the ACM MC2R and served on the orga-nizing and technical committees of numerous conferences. Dr. Youssef isthe recipient of the 2003 University of Maryland Invention of the Year

award for his Horus location determination technology, the 2010 TWAS-AAS-Microsoft Award for Young Scientists, the 2012 Egyptian StateAward, among others.

Khaled A. Harras is an Assistant Professor ofComputer Science at Carnegie Mellon Uni-versity. He is the founder and director of theNetworking Systems Lab (NSL) at the CMU-Qatar campus. His research interests spansdifferent thrusts within computer networksincluding mobile ad-hoc, wireless, sensor, andvehicular networks. He is particularly inter-ested in the design and analysis of architec-tures and protocols for different forms ofchallenged, delay and disruption tolerantnetworks (DTNs). Dr. Harras holds a bachelors

degree in computer science with a double minor in electronics andbusiness administration from the American University in Cairo. He wasawarded the president’s cup and Ahmed. H. Zewail prize from AUC. He

then received his M.S. and Ph.D. in Computer Science from University ofCalifornia in Santa Barbara (UCSB). He is a professional member of theACM and IEEE.