enabling the deployment of cots applications in tactical edge networks

IEEE Communications Magazine • October 201366 0163-6804/13/$25.00 © 2013 IEEE

INTRODUCTION

There is a growing interest in adopting commer-cial off-the-shelf (COTS) hardware and softwaretechnologies in military application environ-ments, such as tactical edge networks (TENs)[1]. In fact, the adoption of COTS technologiesenables reaping the benefits of economies ofscale, and facilitates and hastens the develop-ment and deployment of complex distributedapplications by leveraging robust and widelyadopted standards and software components.

Legacy and COTS applications were (andsometimes continue to be) developed using stan-dards devised for wired Internet environments orcorporate networks, such as service oriented archi-tectures (SOAs) and other web-inspired technolo-gies, and TCP and UDP. When these applicationsare deployed on TENs, their performance is sig-nificantly degraded. In fact, the reliance on webprotocols results in excessive bandwidth utilizationin an environment where bandwidth is alreadyscarce. Reliance on TCP results in decreasedthroughput, decreased bandwidth, and other fail-ures such as connection resets.

In order to support the deployment and reuseof COTS and legacy applications in tactical envi-ronments, there is a need to develop solutionsthat mediate between the communication seman-tics required by the applications and those thatcan be reasonably supported by TENs. Morespecifically, the tactical scenario demands anintelligent substrate that transparently capturesthe data transmitted by the applications, manip-ulates it to reduce its footprint, and remaps itover TEN-specific communication solutions.

This article presents an analysis of the chal-lenges in deploying COTS applications in TENs,which motivated us to develop NetProxy, a state-of-the-art solution explicitly designed to addressthose issues. NetProxy was originally introducedin [2], which focuses on technical aspects of thetool such as its architecture and implementation,and was later extended for the present work.NetProxy is a component of the Agile Comput-ing Middleware, a comprehensive communica-tions solution we designed to support thedevelopment of distributed applications forTENs [3].

We note that while the performance and reli-ability of COTS applications is also a relevantissue with wireless and mobile ad hoc networkenvironments, its importance in TENs is muchmore significant. As a result, we believe that thisis an interesting research area that could lead toresults with impact outside the military applica-tion environment. We hope that this article willattract the interest of researchers working inwireless communications and stimulate them todevelop methodologies and solutions that pushforward the state of the art.

COTS APPLICATIONS AND SOAS INTACTICAL NETWORKS

The deployment of COTS and legacy applica-tions in TENs presents many significant chal-lenges related to the use of softwarearchitectures and communication protocols thatare not suited for highly dynamic and unreliablenetworking environments. More specifically, the

ABSTRACT

The increasing adoption of COTS hardwareand software technologies in tactical scenariosraises the issue of supporting the deployment oflegacy and COTS applications in extremelydynamic and challenging environments such astactical edge networks (TENs). COTS applica-tions adopt standards devised for wired Internetenvironments or corporate networks, such asservice oriented architectures, and TCP andUDP, thus exhibiting severe reliability and per-formance problems on TENs. To support thereuse and deployment of COTS applications inTENs, there is the need to develop solutionsthat mediate the application requirements withthe communication semantics of TENs. Thisarticle presents an overview of the challenges indeploying COTS applications in TENs and pre-sents NetProxy, a state-of-the-art solution explic-itly designed to address them.

MILITARY COMMUNICATIONS

Mauro Tortonesi, Alessandro Morelli, and Cesare Stefanelli, University of Ferrara

Ralph Kohler, US Air Force Research Lab

Niranjan Suri, Florida Institute for Human & Machine Cognition and US Army Research Lab

Scott Watson, Space and Naval Warfare Systems Center

Enabling the Deployment of COTSApplications in Tactical Edge Networks

TORTONESI_LAYOUT_Layout 1 9/27/13 10:37 AM Page 66

IEEE Communications Magazine • October 2013 67

most significant problems exhibited by COTSapplications originate from their reliance onSOAs and TCP.

SOA-based applications typically adopt client-server architectures with long-lived and (semi-) -static bindings between software components. Infact, while the fundamental building block ofSOAs is represented by short-lived operations,that is, synchronous remote procedure calls(RPCs), usually SOA-based clients exploit infor-mation about server locations (e.g., obtainedfrom Web Services Description Language[WSDL] documents) for several subsequentrequests, thus leading to a relatively tight andbrittle coupling between software components.This model is perfectly appropriate for LANs orwired Internet environments but that does notmatch the resilience and adaptivity requirementsof TENs. In fact, applications running in TENsmust deal with frequent disconnections for mul-tiple reasons (nodes might move and fall out ofcommunications range, networks may becomepartitioned, client devices might need to be tem-porarily shut down or stop network activity). Inaddition, TEN applications often need to switchto different service providers, exploiting newresources (e.g., unmanned aerial vehicles,UAVs) as they come in topological proximityand, when possible, leveraging peer-to-peer(P2P) architectures and/or local replicas of dataand services [3].

The coupling between components in SOA-based applications can be loosened via the adop-tion of enterprise message buses (EMBs) thatalso reduce the risk of building stove-piped sys-tems. However, the reliance on COTS messagingsystems and protocols results in applications thatfall short of matching the needs of TENs. Infact, COTS solutions such as JGroups(http://www.jgroups.org/) and Advanced MessageQueuing Protocol (AMQP)-based middlewarebeing proposed and adopted in TENs were notdesigned to withstand temporary network dis-connections between components without dis-rupting service sessions or to support theopportunistic exploitation of resources.

In addition, SOA-based technologies adoptapplication protocols (e.g., HTTP) and middle-ware that hinder the adoption of performanceoptimizations such as request aggregation and/orpipelining and reuse of trasport-layer connec-tions. SOA-based applications also make heavyuse of verbose and bandwidth-expensive XML-based data representation protocols that are anexcessive burden for TENs.

The Marine Corps Systems Command’sMarine Air Ground Task Force (MAGTF) Com-mand & Control (C2) Systems & Applications(SA) Service-Oriented Infrastructure (SOI) rep-resents an illustrative example of how difficult itis to run SOA-based applications in TENs. SOIrelies on the JBoss middleware and variousenterprise message buses. Applications typicallyintegrate with SOI using Apache Qpid, a cross-platform Advanced Message Queuing Protocol(AMQP)-based messaging middleware, convey-ing all the messages over TCP. Therefore, whenrunning on a TEN, those applications will eithernot function or provide poor performance whencommunicating with SOI.

These considerations led to the developmentof SOA-specific solutions, such as DSProxy [4],that facilitate the deployment of SOA-basedCOTS applications in TENs by operating asadapters between the applications and militarygrade store-and-forward communication solu-tions, such as the X400-based STANAG 4406messaging system, and techniques, e.g., requestoptimization and distributed caching, thatimprove the applications’ fault-tolerance andperformance.

However, while proxy-based adaptation hasproved to be a very effective technique forenabling the deployment of SOA-based COTSapplication in military environments, SOA-spe-cific approaches present several significant draw-backs. More specifically, SOA-specific adapterssuch as DSProxy do not consider non-SOA-based COTS and legacy applications and onlyfocus on the optimization of application-levelprotocols.

Instead, there is the opportunity to improvethe performance of COTS applications by apply-ing communication optimization techniques thatoperate contextually at both the application andtransport levels. This is particulary important inCOTS applications that perform long servicesessions and adopt transport-level communica-tion semantics based on the reliable streammodel provided by TCP.

The reliable stream model is not compatiblewith the “always exploit the best connection”operational mode, which is a fundamentalrequirement for TENs. In fact, nodes in a TENoften have more than one communication link;for example, a slow but reliable third generation(3G) connection, a SATCOM connection thatmay not work in bad weather, and/or a fasterlocal connection (e.g., to an airborne relaynode), which is not always available. To achievethe best performance, applications (and the mid-dleware) need to dynamically switch between theavailable links to exploit the best connectivity.However, TCP-based applications are not capa-ble of dynamically switching service sessionsbetween different network interfaces, thus forc-ing users to manually shut down service sessionsand restart them in order to take advantage offaster (and cheaper) links when available. Notethat while similar issues are also actively studiedin Third Generation Project Partnership (3GPP)networks [5], the need to always exploit the bestconnection in TENs is an even more importantand complex issue due to the wide heterogeneityof link types.

In fact, the mismatch between the semanticsof transport-layer protocols on which COTSapplications are built and those that could bereasonably provided over TENs also represents amajor issue. At the transport protocol level,COTS applications leverage the semantics pro-posed by commonly used protocols, such as TCPand UDP, which provide reliable and sequenceddelivery of a stream of data and unreliable unse-quenced delivery of messages, respectively.

TCP and similar protocols are also very inef-ficient in highly dynamic environments such asTENs. In fact, TCP implements a single first-infirst-out (FIFO) transmission queue and doesnot enable applications to liberate the queue

The deployment of

COTS and legacy

applications in TENs

presents many

significant challenges

that are related to

the use of software

architectures and

communication

protocols that are

not suited for highly

dynamic and unreli-

able networking

environments.


IEEE Communications Magazine • October 201368

from stale data waiting for (re)transmission (anoperation that the stream-oriented nature ofTCP, which does not preserve the boundariesbetween messages, would also make rather diffi-cult to implement). In cases where the informa-tion generation rate outpaces the networkcapability, this limitation forces the transmissionof obsolete messages, significantly reducing theapplications’ goodput. The negative impact ofthe TCP queuing model on latency is also wellrecognized in wired Internet environments [6].However, these issues are further exacerbated inTEN applications by the time-sensitive and mul-tiple-priority nature of traffic, and by the adop-tion of peculiar and high-latency communicationsolutions, such as tactical radio links withDAMA modulation that implement two-partycommunications over unidirectional links.

In addition, in wireless environments, TCPimplementations often misinterpret packet losses(caused by higher channel error rate, mediumcontention/collision, and/or node mobility) ascongestion symptoms and consequently triggercongestion control mechanisms that significantlyreduce the transmission rate. This approachleaves the wireless channel underutilized andgenerates traffic flows with lower throughputand higher latency than the network is actuallycapable of delivering.

At the other end of the spectrum, UDP doesnot provide reliability levels or flexible mecha-nisms for group communications suited for TENcommunications. In fact, the best-effort deliverysemantics implemented by UDP places the bur-den of ensuring the delivery of important mes-sages on the applications, for instance byimplementing ad hoc retransmission schemes.UDP broadcast communications are also inade-quate as a basic mechanism for group communi-cation in TENs, which instead call fordisruption-tolerant communication schemes.

The limitations of TCP and UDP have amajor impact on COTS and legacy tactical appli-cations that typically leverage TCP for reliableend-to-end communication and UDP for besteffort broadcast/multicast communications. Anexample of these legacy applications is GeoChat,a multi-user chat application that is part of theAir Force Special Operations Command’s Bat-tlefield Air Operations (BAO) Kit. GeoChatuses TCP for file exchange, incurring relativelyfrequent failures and low performance, andUDP multicast for chat messages, incurring fre-quent loss of messages.

Instead, TEN applications are better servedby communication solutions that provide a widerrange of delivery semantics, thus enabling thedifferentiation of delivery mechanisms accordingto the importance of the messages being trans-mitted. In particular, reliable and sequenceddelivery (as provided by TCP) is very expensiveand should be used only when absolutely neces-sary. The importance of providing customizabledelivery mechanisms in wireless environments iswidely recognized, as demonstrated by recentresearch efforts on SCTP, which supports multi-ple streams, multiple associations, and partialreliability mechanisms [7]. In fact, state-of-the-art TEN-specific communication solutions recog-nize the need for smart buffer management and

go beyond the features provided by SCTP byalso enabling fine-grained control of messagedelivery semantics and mobile service sessions[1].

Finally, the limited bandwidth available forcommunications in the tactical environmentrequires applications to adopt communicationschemes that are as efficient as possible. Howev-er, COTS applications were typically designedfor wired Internet environments with theassumptions of having frequent and evenly dis-tributed transmission opportunities and lowround-trip times. As a result, they often imple-ment rather simple communications schemesthat do not adopt any optimization, for example,by aggregating or parallelizing requests orreusing already established connections for fol-lowing requests [8]. These assumptions do nothold in TENs, thus leading to very poor perfor-mance results.

BRIDGING THEIMPEDANCE MISMATCH

Running COTS applications on top of communi-cation solutions specifically designed for TENs isoften impossible or impractical, as it requiresmodifications to the applications’ source code.Clearly, this approach cannot be applied to thirdparty or legacy software, because either theapplications’ source code is not available or therequired modifications would be too expensive.

Instead, an interesting approach relies on thedevelopment of specific adaptation componentsor middleware to enable the deployment ofCOTS and legacy applications over TEN-specificcommunication solutions. This approach followsa school of research, dating as far back as 1995,with proposals such as I-TCP [9], Mobile-TCP[10], and the Remote Sockets Architecture [11],which investigates proxy-based architectures toaddress both the performance and mobilityissues TCP exhibits in wireless networks. Morerecent proposals, such as A3 [12], suggest theadoption of transparent proxies and sophisticat-ed buffer and message management solutions toaccelerate TCP-based applications in wirelessenvironments.

Despite their interesting potential, so farproxy-based solutions have mostly focused onthe application performance improvementsinstead of the adaptation between different com-munication models and/or protocols. In addition,those solutions have received limited interestfrom researchers, who instead have preferred tofocus on the development of new protocols orwireless-friendly TCP implementations. Howev-er, the deployment of COTS and legacy applica-tions on TENs calls for an intelligent substratethat lies between COTS applications and TEN-specific communication solutions, thus makingproxy-based solutions a key technology to bridgethe impedance mismatch between these two soft-ware layers.

More specifically, the adaptation substrateshould use proxy components to implement thetransparent remapping of traditional TCP- (orUDP-) based communication semantics, adoptedby COTS applications, to TEN communication

An interesting

approach relies on

the development of

specific adaptation

components or mid-

dleware to enable

the deployment of

COTS and legacy

applications over

TEN-specific commu-

nication solutions.

This approach fol-

lows a school of

research, dating as

far back as 1995.



middleware, e.g., for information disseminationor for mobile sessions support. At the receiverside, another proxy instance should translate thereceived data back to the applications through aTCP- (or UDP-) based interface.

The proxy-based approach has the advantageof being application-transparent. It works withCOTS applications without requiring any modifi-cations and without breaking the expected TCP-or UDP-based communication semantics. It alsodoes not leak any abstraction or concept ofTEN-specific communication solutions to thehigher software layers. By providing adaptationfeatures at the proxy level, all applications canimmediately benefit from the functions providedby communication solutions explicitly designedfor TENs without any modification.

At the same time, the proxy-based approachenables the realization of an adaptation sub-strate that is both application-aware and net-work-aware, which can therefore put in placespecific solutions to optimize communicationsaccording to the specific COTS applicationrequirements (or semantics) and the currentoperating conditions. For instance, for someapplications, it could leverage peer-to-peer(P2P) communications or opportunistic informa-tion dissemination solutions. For other applica-tions, it could tailor the communicationsaccording to the current state of the network,prioritizing the transmission of essential mes-sages and discarding (or deprioritizing) messagesof secondary importance according to the avail-able bandwidth.

Therefore, the proxy-based approach repre-sents a very effective solution that is particularlywell suited to support the deployment of COTSand legacy applications in TENs.

THE AGILE COMPUTINGMIDDLEWARE NETPROXY SOLUTION

Following the approach described in the previ-ous section, we designed NetProxy, a solutionthat transparently intercepts any (TCP- or UDP-based) network traffic generated by COTS appli-cations, analyzes it, and conveys it overpoint-to-point connections and/or point-to-multi-point information dissemination channels pro-vided by the Mockets and DisServicecommunication middlewares.

The Mockets middleware is a communicationsolution explicitly designed to address the issuesthat the standard communication protocols, suchas TCP and UDP, exhibit on TENs. Mocketsenables the smart management of transmissionbuffers, allowing applications to exploit differentdelivery semantics and transmission priorities fordifferent classes of messages, discard obsoletedata in the transmission queue, and so on. Inaddition, Mockets supports session mobility anddynamic service rebinding, and implementsmechanisms that monitor the current networkstate and export that state to the applications,enabling them to detect connection loss, monitornetwork performance, and react accordingly(e.g., by tailoring their quality of service, QoS).Unlike TCP, the Mockets middleware does notassume to operate over low-error-rate channels,

but implements an adaptable congestion controlmechanism that is specifically devised for thechallenges that are characteristic of the mobilead hoc environment. Additional details on theimproved performance of Mockets on TENs aredescribed in [1]. The challenge, addressed by theNetProxy described in this article, is enablingCOTS and legacy applications to benefit fromMockets without having to modify them.

DisService, on the other hand, is a P2P infor-mation dissemination solution specificallydesigned to support dynamic network topologiesand highly mobile nodes such as UAVs [3, 13].DisService enables nodes to participate in multi-ple groups of interest, which communicatethrough independent information disseminationchannels (subscriptions), thereby supporting themultiple patterns of data dissemination requiredby tactical applications. DisService enables dis-ruption-tolerant information dissemination andrelies on store-and-forward communications,aggressive distributed data caching, and oppor-tunistic resource (communications, storage, andprocessing capacity) management to improve theperformance of the information disseminationprocess. DisService also implements an adaptivecontact prediction mechanism that detects recur-rent mobility patterns of highly dynamic nodes,such as UAVs loitering over the battlefield, anduses this knowledge to optimize the informationdissemination process.

Mockets and DisService represent comple-mentary solutions that address a large number ofthe communication requirements in TEN envi-ronments. NetProxy, whose architecture isdepicted in Fig. 1, relies on Mockets and DisSer-vice to provide COTS applications with commu-nication solutions well suited for TENs. Mockets,DisService, and NetProxy are components of theAgile Computing Middleware.

More specifically, NetProxy operates trans-parently to COTS applications by capturing theirTCP and UDP packets, extracting their payload,processing the data according to the application-specific traffic management configuration, andhanding them over to Mockets or DisService forefficient delivery to the destination. At thereceiver side, another instance of NetProxy per-forms the inverse task. NetProxy also supportstemporary disconnection, stream compression,and network activity logging.

While the proxy-based approach introducessome overhead, our experience demonstratesthat the performance gains stemming from moreefficient and target-appropriate protocols signifi-cantly outweigh the computational burden andlead to major performance improvements over-all. In addition, NetProxy enables devisingsophisticated application-specific optimizationsthat can improve the performance of COTSapplications even further.

CONVEYING COTS APPLICATIONS’ TRAFFICOVER TEN-SPECIFIC COMMUNICATION

SOLUTIONS

To optimize the performance of COTS applica-tions on TENs, NetProxy provides traffic manip-ulation functions and enables implementation ofuser-defined policies for the smart management

While the proxy-

based approach

introduces some

overhead, our experi-

ence demonstrates

that the perfor-

mance gains stem-

ming from more

efficient and target-

appropriate proto-

cols significantly

outweigh the com-

putational burden

and lead to major

performance

improvements

overall.



of traffic. This allows addressing the manyrequirements COTS applications might have.

More specifically, users can configure Net-Proxy with policies that target specific communi-cations (e.g., depending on the type of traffic,the protocol being utilized, or the source/desti-nation addresses). Policies can be dynamicallyupdated at runtime, without stopping andrestarting running applications. This provides astandard and centralized configuration point forall the functionalities provided by NetProxy,allowing for faster and easier management ofthe communication flows in the network.

NetProxy supports many different trafficmanipulation functions. For instance, NetProxyallows the forwarding of traffic over a Mocketsservice session, a DisService subscription, orboth. This might be suited for COTS applica-tions that issue notifications to a server, as ithelps to disseminate information to other nodesthat might be interested.

In addition, by leveraging the session mobilityfeature provided by Mockets, NetProxy cantransparently rebind local service session end-points to a different network interface, takingadvantage of faster (and cheaper) links whenavailable. This addresses the issues of deploy-ment scenarios, commonly found in TENs, wherenodes have several links (e.g., SATCOM, 3G,airborne relay, and/or Wi-Fi) and need to switchbetween them to exploit the best possible con-nectivity.

NetProxy also provides application-specificmechanisms that significantly improve the appli-cations’ robustness and performance throughrelatively straightforward reconfigurations ormodifications. In fact, while for some applica-tions the simple adoption of generic solutions(e.g., standard data compression mechanisms)will deliver significant performance improve-ments, other applications might require specificand more sophisticated schemes.

NetProxy enables the performance opti-mization of important applications throughthe definition and implementation of applica-tion-specific management policies/configura-t ions and the development of dedicatedacceleration plugins. Plugins have to provide aset of rules that enable NetProxy to identify

the traffic belonging to the applications forwhich they are designed and to implement asimple callback interface that enables them tointegrate with the NetProxy traffic manipula-tion function.

A particularly interesting optimization tech-nique involves the adoption of application-spe-cific transcoding and compression schemes. Forinstance, it is often possible to reduce the size ofrequest and response messages of COTS appli-cations that rely heavily on XML by switching tomore efficient data representation and docu-ment format, such as JavaScript Object Notation(JSON). In addition, compression of messagecontent before the actual transmission is often avery effective way to reduce bandwidth con-sumption. However, some applications cannotadopt generic full-payload compression schemes.This is especially true with HTTP-based applica-tions that often have to traverse middleboxessuch as load balancers that operate on theassumption that HTTP headers are readable andquickly accessible. The adoption of generic com-pression schemes would break these distributedapplication setups, which instead call for applica-tion- (or, more precisely, protocol-) specificcompression schemes. In addition, compressionschemes need to be deployed on a case by casebasis, as sometimes they might increase latencyand, with resource constrained clients, may becomputationally too expensive.

Another very compelling application-specificoptimization involves request optimization. Bydeveloping application-specific plugins thatleverage knowledge about the communicationsemantics of COTS applications, it is possible tooptimize the applications’ performance byautomating the transmission of requests that theCOTS application is likely to perform, or imple-menting request desequencing/parallelizationschemes.

Application-specific plugins could also beused to enhance the applications’ resilience andfault tolerance. For instance, applicable pluginscould act as adapters that provide a more robustservice interface in front of existing services.This could turn stateful interactions into a seriesof idempotent operations, which are widely rec-ognized as a fundamental tool to implementresilient services [14].

In addition, NetProxy enables sophisticatednetwork-aware traffic management policies thatpermit enforcing different delivery mechanismsand priorities according to the specific type oftraffic and the current network condition. Forinstance, if the quality of the communicationlink degrades, NetProxy can be configured toenforce reliable delivery only for critically impor-tant messages while transmitting all the othermessages in a best effort fashion, or discardingthem after the expiration of the lifetime or maxi-mum retransmission count attribute associatedwith the messages. When the network conditionsimprove, NetProxy might resume using reliabledelivery for each message that is transmitted.

Finally, NetProxy facilitates the reuse ofexisting connections for multiplexing multipleconnections at the application level. While thismight seem a rather straightforward optimiza-tion, in our experience it often leads to signifi-

Figure 1. NetProxy architecture and interface with applications and lower-levelcommunication solutions.

NetProxy

Mockets DisService

Application-specific

transcodersDecisionmaking

COTS application

Networkstate

Configurationfiles

ConfigurationmanagerQueue manager



cant performance optimization, as demonstratedby the first experiment presented in the next sec-tion.

EXPERIMENTAL RESULTSTo demonstrate the effectiveness of proxy-basedsolutions to support the deployment of COTSapplications in TENs, we present the resultsobtained from two different experiments. Theexperiments are designed to reproduce and illus-trate common issues that COTS applicationsexhibit in TENs.

To evaluate the performance of the combineduse of the NetProxy and Mockets middleware,and to compare this solution to TCP, we ran theexperiments in an emulated environment, whichallowed us to reproduce the characteristics of aTEN. More specifically, we used an enhancedversion of the Mobile Ad Hoc Network Emula-tor (MANE) [15], a tool designed to reproducethe characteristics of unreliable environmentssuch as TENs, to set up the connectivity betweenthe nodes involved in the testing.

The nodes are part of the NOMADS testbed,which comprises 96 servers connected through a100 Mb/s Ethernet LAN. The hardware configu-ration of the machines consists of HP DL140servers (Dual Xeon dual core CPUs at 3.06GHz, with 4 Gbytes of RAM). MANE can con-trol bandwidth, latency, and reliability for eachlink, thus allowing the evaluation of differentsystems and protocols in a reproducible, labora-tory controlled environment. The reliabilityparameter is based on the packet error rate(PER); hence, a 90 percent reliability value isequal to a 10 percent PER value.

For the first experiment, we wrote a simpleclient application that generates an HTTP SOAPrequest, sends it to a web server located onanother node of the testbed, and waits for theresponse. The application was also responsiblefor measuring the throughput. We kept thebandwidth of the link stable at the value of 1Mb/s throughout the experiment, while we con-sidered the reliability values of 87, 90, 93, and 95percent. We configured the client application torepeat the request 50 times with the same linkconditions before we modified the configurationof MANE to vary the reliability of the link.

Figure 2 shows the results obtained by run-ning the experiment described above, connectingclient and server using TCP, TCP via NetProxy,and Mockets via NetProxy. The higher through-put achieved by Mockets and NetProxy clearlystands out from the graph. It is also worth not-ing that TCP via NetProxy performs better thanplain TCP. The reasons for this behavior aremanyfold. First of all, many standard SOAPimplementations, such as Apache Axis 2(http://axis.apache.org/axis2/java/core/), bydefault send every SOAP request using a sepa-rate TCP connection. This means that a largeportion of the traffic is sent during the TCP slowstart phase, which significantly limits bandwidthusage. This issue does not occur with NetProxy,which multiplexes all the traffic directed to a sin-gle node onto the same connection, reusing itfor following requests. Furthermore, NetProxyhas a buffering mechanism that allows the gener-

ation of larger TCP segments, thereby reducingthe protocol overhead.

Figure 3 shows the results obtained runningthe same experiment after enabling the compres-sion feature in NetProxy. We used Mockets viaNetProxy to send data between the two nodeswhile varying the compression algorithm. Thefigure shows that with compression enabled, wecould achieve a very high gain in the measuredthroughput. This is due to the verbosity of theHTTP and SOAP protocols, which can thereforebe compressed very efficiently. Despite the bet-ter compression ratio of LZMA compared toZlib, the use of Zlib resulted in higher through-put. This is due to the higher demands on com-putational resources required by LZMA.

For the second experiment, we used ApacheQpid (http://qpid.apache.org/) to build a basicpublish-subscribe architecture. Figure 4 pre-sents the configuration we used for the experi-ment. Two instances of Qpid (Qpid A and QpidB) were running on two different nodes of thetestbed, and two applications, a publisher and asubscriber, were running on a third node. (Thepublisher and subscriber were located on thesame machine to enable accurate time mea-surements.) The subscriber registered itself toQpid B, while the publisher published messages

Figure 2. Measured throughput running the experiment with: a) TCP; b) TCPvia NetProxy; c) Mockets via NetProxy.

Channel reliability87.00%

10

Thro

ughp

ut (

kbyt

es/s

)

0

20

30

40

50

60

70

80

90

90.00% 93.00% 95.00%

Plain TCPTCP via NetProxyMockets via NetProxy

Figure 3. Measured throughput running the experiment wih Mockets via Net-Proxy and: a) compression disabled; b) Zlib compression; c) LZMA com-pression.

Channel reliability87.00%

100

Thro

ughp

ut (

kbyt

es/s

)

0

200

300

400

500

600

700

800

90.00% 93.00% 95.00%

Plain dataZLIBLZMA


to Qpid A. To dispatch the published messagesto the subscriber, Qpid A was connected toQpid B. We configured the connectionsbetween the publisher and subscriber applica-tions and the relative Qpid instances to useTCP over the 100 Mb/s Ethernet LAN providedby the NOMADS testbed, while we usedMANE to configure the link between the twonodes running the Qpid instances. The nodeswe used in this experiment were CentOS 6.2Linux virtual machines (VMs), each VM run-ning on an Ubuntu 8.04 LTS server. Again, wefixed the link bandwidth to 1 Mb/s usingMANE, and then repeated the experiment withthe values 85, 90, and 95 percent for the linkreliability parameter. To collect the results, thepublisher published 10 copies of messages of100, 256, and 512 kbytes for each reliability set-ting, and then measured the throughput.

Figure 5 shows the results of the secondexperiment. They are divided into three charts,based on the message size, which graph theaverage measured throughput. The resultsdemonstrate that while the performance ofboth the solutions decreases with the decreaseof the link reliability, the decreasing trend ofTCP is much steeper than with NetProxy andMockets. Moreover, in almost all the tests, thestandard deviation measured when relying onMockets and NetProxy to connect the nodeswas lower than the standard deviation mea-sured when TCP was used. The results alsoshow that the transport protocol implementedby Mockets still has room for improvementswhen employed over reliable links. However,our past experience with the use of Mockets inreal TEN scenarios has always exhibited signifi-cant improvements in terms of goodput, laten-cy, and temporary connection disruptiontolerance when compared to traditional TCP-based solutions. We found that the reason layin the relatively high number of packet retrans-missions occurring during the experiments,which corresponds to an average PER levelhigher than 10 percent.

CONCLUSIONS

Proxy-based technologies represent an inter-esting and very effective approach to enablethe deployment of COTS appl icat ions inTENs. The potential of proxies in increasingthe appl icat ions ’ robustness and perfor -mance is so significant that their adoptiondeserves to be inves t igated beyond TENenvironments.

The diffusion of proxy-based technologiescould open up very interesting scenarios. First, itcould lead to a world in which SOA- and TCP-based interfaces are perceived by developers as acommodity. Applications will be built on top ofthem and engineers will use proxies to deploythose applications anywhere.

In addition, tools like NetProxy enable themanagement of the security-related configura-tion of several applications in a single place atthe proxy level. This facilitates the deploy-ment of not secure-by-design COTS applica-tions in security-critical environments such asTENs.

Proxy-based adapters could open the way forexperimental development tools for SOA-basedapplications that automate application-specifictraffic management or that support the develop-ment of dedicated plugins for proxy-based solu-tions. For instance, such tools could leverageadditional (semantic) information inserted inWSDL documents via annotation schemes. Thisrepresents a very promising research directionthat we are planning to explore within the Net-Proxy project in the near future.

We are also planning to test the NetProxydynamic (re-)configuration capabilities and toevaluate its performance with additional com-monly used COTS applications. These resultswill be reported in future publications.

REFERENCES[1] N. Suri et al., “Communications Middleware for Tactical

Environments: Observations, Experiences, and LessonsLearned,” IEEE Commun. Mag., vol. 47, no. 10, SpecialIssue on Military Communications, Oct. 2009, pp. 56–63.

[2] A. Morelli et al., “Supporting COTS Applications in Tac-tical Edge Networks,” Proc. IEEE MILCOM 2012, 29Oct.–1 Nov.2012, Orlando, FL.

[3] N. Suri et al., “Peer-to-Peer Communications for TacticalEnvironments: Observations, Requirements, and Experi-ences,” IEEE Commun. Mag., vol. 48, no. 10, Special Issueon Military Communications, Oct. 2010, pp. 60–69.

[4] K. Lund et al., “Robust Web Services in HeterogeneousMilitary Networks,” IEEE Commun. Mag., vol. 48, no.10, Special Issue on Military Communications, Oct.2010, pp. 78–83.

[5] M. Louta and P. Bellavista, “Bringing Always Best Con-nectivity Vision a Step Closer: Challenges and Perspec-tives,” IEEE Commun. Mag., vol. 51, no. 2, Feb. 2013,pp. 158–66.

[6] A. Erbad, C. Krasic, “Sender-side Buffers and the Casefor Multimedia Adaptation,” ACM Queue, vol. 10, no.10, Oct. 2012.

[7] Ł. Budzisz et al., “A Taxonomy and Survey of SCTPResearch,” ACM Computing Surveys, vol. 44, no. 4,article 18, Aug. 2012.

[8] K. Fall and S. McCanne, “You Don’t Know Jack aboutNetwork Performance,” ACM Queue, vol. 3, no. 4, May2005, pp. 54-59.

[9] A. Bakre and B. Badrinath, “I-TCP: Indirect TCP forMobile Hosts,” Proc. 15th IEEE Int’l. Conf. Distrib. Com-puting Sys., 1995.

[10] Z. Haas, “Mobile-TCP: An Asymmetric Transport Proto-col Design for Mobile Systems,” Proc. 3rd Int’l. Wksp.Mobile Multimedia Communications, 1995.


Figure 4. Configuration for the second experiment.

NetProxy

Publisherapplication

Subscriberapplication

NetProxy

CentOS 6.2 VMover Ubuntu 8.04

LTS server


LTS server

TCP over 100MbpsEthernet LAN

TCP over 100MbpsEthernet LAN


LTS server

Mockets overMANE-

controlled link

Qpid A Qpid B

TORTONESI_LAYOUT_Layout 1 9/27/13 10:37 AM 2


[11] M. Schlager et al., “Advocating a Remote SocketArchitecture for Internet Access Using Wireless LANs,”Mobile Networks and Applications, vol. 6, no. 1,Jan./Feb. 2001, pp. 23–42.

[12] Z. Zhuang et al., “Application-Aware Acceleration forWireless Data Networks: Design Elements and Proto-type Implementation,” IEEE Trans. Mobile Computing,vol. 8, no. 9, Sept. 2009.

[13] M. Tortonesi et al., “Multiple-UAV Coordination andCommunications in Tactical Edge Networks,” IEEE Com-mun. Mag., vol. 50, no. 10, Special Issue on MilitaryCommunications, Oct. 2012, pp. 48–55.

[14] P. Helland, “Idempotence Is Not a Medical Condition,”ACM Queue, vol. 10, no. 4, Apr. 2012.

[15] Mobile Ad-Hoc Network Emulator (MANE);http://cs.itd.nrl.navy.mil/work/mane/index.php

BIOGRAPHIESRALPH KOHLER, JR. [F] ([email protected]) is a principalengineer at the U.S. Air Force Research Laboratory, wherehis primary research interests are the nexus of informationmanagement, wireless and tactical networks, and the capa-bilities that combining the two make possible. He receivedhis Master’s degree from Syracuse University and is a mem-ber of the AIAA.

ALESSANDRO MORELLI ([email protected]) receivedhis B.Sc. degree in information engineering and M.Sc.degree in computer science engineering from the Universi-ty of Ferrara, Italy. He is currently a Ph.D. student in theEngineering Department of the University of Ferrara. Hisresearch interests focus on distributed and mobile comput-ing, opportunistic networking, and smart cities.

CESARE STEFANELLI [M] ([email protected]) receivedhis Laurea degree in electronic engineering and his Ph.D. incomputer science engineering from the University ofBologna, Italy. He is currently a full professor of computerscience engineering in the Engineering Department of theUniversity of Ferrara. His research interests include dis-tributed and mobile computing, adaptive and distributedmultimedia systems, network and systems management,and network security.

NIRANJAN SURI [M] ([email protected]) is a research scientist atthe Florida Institute for Human & Machine Cognition andalso a visiting scientist at the U.S. Army Research Laborato-ry, Adelphi, Maryland. He received his Ph.D. in computerscience from Lancaster University, England, and his M.Sc.and B.Sc. in computer science from the University of WestFlorida, Pensacola. His current research activity is focusedon the notion of agile computing, which supports theopportunistic discovery and exploitation of resources inhighly dynamic networked environments. His other researchinterests include coordination algorithms, distributed sys-tems, networking, communication protocols, virtualmachines, and software agents.

MAURO TORTONESI [M] ([email protected]) receivedhis Laurea degree in electronic engineering and his Ph.D. incomputer science engineering from the University of Fer-rara, Italy. Currently, he is an assistant professor in theEngineering Department of the University of Ferrara. Hisresearch interests include distributed and mobile comput-ing, QoS management, network and service management,business-driven IT management, and e-maintenance.

SCOTT WATSON ([email protected]) is a senior systemsarchitect with the Composeable Services Branch of theCommand and Control Department of the Space and NavalWarfare Systems Center — Pacific. He has over 10 years’experience designing software systems and applications.He is currently the principal investigator for the MobileModular Command and Control for Company Level Opera-tions (M2C3) project. He has a B.S. in computer sciencefrom San Diego State University, California. He recentlyreceived the Navy Civilian Meritorious Service award forwork in the area of disruption-tolerant networking.

Figure 5. Average measured throughput (in kilobytes per second) for messagesof different sizes: a) 100 kbytes; b) 256 kbytes; c) 512 kbytes; and channel reli-ability set to 95, 90, and 85 percent. Reported results refer to tests run withTCP and Mockets via NetProxy.

100 kbytes

95%

40.00

20.00

0.00

60.00

80.00

100.00

120.00

140.00

90% 85%

512 kbytes

(c)

(b)

(a)

95%

40.00

20.00

0.00

60.00

80.00

100.00

120.00

140.00

90% 85%

256 kbytes

95%

40.00

20.00

0.00

60.00

80.00

100.00

120.00

140.00

90% 85%

TCPMockets via NetProxy




enabling the deployment of cots applications in tactical edge networks

Documents