NetProxy
The ACM NetProxy is a network proxy solution devised to enable the reuse of commercial off-the-shelf (COTS) and Service-Oriented Architecture (SOA)-based applications in extremely challenging networking environments, such as tactical edge networks (TENs). NetProxy is able to satisfy applications' requirements in these scenarios by intercepting the generated traffic, applying application-aware transformation to the data, and remap the communication over TEN-specific communication solutions. The NetProxy is a component of the Agile Communication Middleware (ACM).
Communication Issues in Tactical Edge Networks
Unlike wired Internet environments, applications running in Tactical Edge Networks must deal with disconnections for multiple reasons (nodes could move and fall out of communications range, networks may become partitioned, client devices may need to be temporarily shut down or to stop network activity). They need to implement resilient behavior, allowing temporary disconnections without interrupting service sessions.
In this scenario, the communication semantics proposed by TCP, the transport-level protocol commonly used by SOA technologies (e.g., HTTP and SOAP) and to implement Remote Procedure Calls (RPCs), which provide reliable and sequenced delivery of a stream of data, are inefficient. SOA-based applications also make heavy use of verbose and bandwidth-expensive XML-based data representation protocols that are an excessive burden for TENs. In addition, TCP was designed to operate in wired networks, where it is reasonable to assume that any packet loss is due to congestion. In TENs, many problems (such as higher channel error-rates, medium contention/collision, and node mobility) increase the likelihood of losing packets, which in turn trigger congestion control algorithms in TCP. This decreases transmission rates in order to reduce potential collisions, thereby generating traffic flows with lower throughput and higher latency than the wireless link is actually capable of delivering.
On the other hand, UDP does not provide reliability levels or flexible mechanisms for group communications suited for TEN communications. In fact, the best-effort delivery semantics implemented by UDP places the burden of ensuring the delivery of important messages on the applications, for instance by implementing ad hoc retransmission schemes. UDP broadcast communications are also inadequate as a basic mechanism for group communication in TENs, which instead call for disruption-tolerant communication schemes.
To minimize communication overhead, applications should take advantage of a wide range of delivery semantics, not limited to those provided by TCP and UDP. In particular, reliable and sequenced delivery (as provided by TCP) is very expensive and should be used only when absolutely necessary. Finally, the limited bandwidth available for communications in the tactical environment requires applications to adopt communication schemes that are as efficient as possible. However, COTS applications were typically designed for the wired Internet environment and, as a consequence, they often implement rather simple, unoptimized communications schemes.
The NetProxy Solution
The NetProxy intercepts the traffic generated by applications on a node and remaps traditional TCP- (or UDP-) based communication semantics, adopted by COTS applications, to TEN-specific communication middleware components, e.g., DisService for the information dissemination in case of broadcast/multicast communications, or Mockets for reliable, efficient transmissions or for support to session mobility. At the receiver side, another proxy instance should translate the received data back to the applications through a TCP- (or UDP-) based interface. The architecture of NetProxy and its interactions with other components of ACM are shown in Figure 1.
The proxy-based approach has the advantage of being application-transparent. It works with COTS applications without requiring any modifications and without breaking the expected TCP- or UDP-based communication semantics. It also does not leak any abstraction or concept of TEN-specific communication solutions to the higher software layers. By providing adaptation features at the proxy level, all applications can immediately benefit from the functions provided by communication solutions explicitly designed for TENs without any modification. At the same time, the proxy-based approach enables the realization of an adaptation substrate that is both application-aware and network-aware, which can therefore put in place specific solutions to optimize communications according to the specific COTS application requirements (or semantics) and the current operating conditions.
The NetProxy supports additional features, to further increase efficiency:
Gateway/Host mode. The NetProxy can run in two different operational modes: Host mode (HM) and Gateway mode (GM). They differ in the way the NetProxy intercepts applications' traffic. While HM requires that an instance of NetProxy is installed on each node that requires the advantages provided by the proxy or by other components of the ACM (through communication remapping in NetProxy), GM allows to install only one instance of NetProxy in a subnetwork. The two operational modes each offer a different set of advantages and it allows the NetProxy to be used under different network configuration constraints.
Target-specific configurations. Users can configure NetProxy with policies that affects only specific communications (based on the type of traffic, the protocol utilized, or the source/destination addresses pair). Policies can be dynamically updated at runtime, without having to stop and restart applications.
Traffic manipulation. NetProxy supports many different application-specific traffic manipulation functions: the remapping of traffic over a Mockets service session, a DisService subscription, or both; traffic forwarding (useful to implement distributed monitoring or logging features); traffic filtering (e.g., to reduce the footprint of some applications); intelligent buffering (e.g., to wrap multiple UDP datagrams into a single message, or to consolidate TCP segments into a smaller number of packets); flow prioritization (for instance, to reallocate bandwidth to specific applications in case of a resource shortage).
Data compression. NetProxy can improve the applications’ performance by applying application-specific data compression techniques. This is incredibly effective in case of COTS applications that rely heavily on verbose XML messages, for which compression can significantly reduce bandwidth usage.
Connection Multiplexing. NetProxy facilitates the reuse of existing connections for multiplexing multiple connections at the application level.
Traffic Monitoring. NetProxy allows the recording of all incoming/outgoing network traffic on the node, with configurable levels of details.
Figure 1. The NetProxy architecture and its interactions with the other ACM middleware components.
Source Code
The source code is open source, licensed under the GNU General Public License version 3 (GPLv3), and available on GitHub at the address:
https://github.com/ihmc/nomads/tree/master/aci/cpp/netProxy
Publications
Tortonesi, M.; Morelli, A.; Stefanelli, C.; Kohler, R.; Suri, N.; Watson, S., "Enabling the deployment of COTS applications in tactical edge networks," Communications Magazine, IEEE , vol.51, no.10, pp.66,73, October 2013
Morelli, A.; Kohler, R.; Stefanelli, C.; Suri, N.; Tortonesi, M., "Supporting COTS applications in Tactical Edge Networks," MILITARY COMMUNICATIONS CONFERENCE, 2012 - MILCOM 2012 , vol., no., pp.1,7, Oct. 29 2012-Nov. 1 2012
Benincasa, G.; Casini, E.; Lenzi, R.; Morelli, A.; Benvegnu, E.; Suri, N.; Boner, K.; Watson, S., "Extending Service-Oriented Architectures to the tactical edge," MILITARY COMMUNICATIONS CONFERENCE, 2012 - MILCOM 2012 , vol., no., pp.1,7, Oct. 29 2012-Nov. 1 2012
In collaboration with:
Florida Institute for Human and Machine Cognition
United States Air Force Research Lab
