Collaborative Networking Towards Application-Aware Networking

Introduction

Todays’ networks, whether public or private, are challenged to support and thus deliver rapidly increasing amounts of traffic having distinct requirement on underlying networks. Also, new channels for originating and consuming rich media are deployed at a rapid pace. Pervasive video and on-demand access are becoming second nature to consumers. Applications make extensive use of rich media, placing unprecedented quality of experience (QoE) demands on the underlying networks. These trends present challenges for network planning (including traffic forecast).

In order to deliver services as expected by users and set by applications themselves, now more so than ever before, identification and differential treatment of flows are critical for the successful deployment and operation of applications, especially in the post-covid era whore more and more sensitive services have to be carried over the Internet. These applications use a wide range of signaling protocols and are deployed by a diverse set of application providers that are not necessarily affiliated with the network providers across which the applications are used (i.e., application flows are forwarded). Network Operators often rely upon identification capabilities to deploy and therefore support a wide range of applications with the adequate quality. Such applications generate flows that may have specific characteristics and requirements such as bandwidth or latency constraints that can be met if made known to the network.

Historically, the identification of application flows has been accomplished using heuristics that infer flow characteristics based on transport port number ranges (e.g., TCP/25), network separation, or inspection of the flow itself. These inspection techniques include, but not limited to:

• •

  Deep packet inspection (DPI), which matches against characteristic signatures (e.g., key string, binary sequence).

• •

  Deep flow inspection (DFI), which analyzes statistical characteristics (e.g., packet length statistics like ratio of small packets, ratio of large packets, small payload standard deviation) and connection behavior of flows.

Each of these techniques suffers from limitations, particularly in the face of the challenges outlined previously.

Heuristic-based approaches may not be efficient and require continuous updates of application signatures. Port-based solutions suffer from port overloading and inconsistent port usage. Network separation techniques like IP sub-netting are error prone and increase network management complexity. DPI and DFI are computationally expensive, prone to error, and become more challenging with greater adoption of encrypted signaling and secured media. An additional drawback of DPI and DFI is that any insights developed at one network node are not available, or need to be recomputed, at nodes further down the application flow path.

The goal of the Application-Aware Networking (AAN) framework is to offer mechanisms that allow applications to request differential network treatment for their flows and to learn what the network can do for them while preserving flow encryption practices. The intent is for the applications to have the ability: (1) to initiate information exchanges in order to provide a more precise allocation of network resources and thus a better user experience, while ensuring security for the flow data, and for application flows to convey metadata that will be by the underlying network to provide a differentiated forwarding and process service.

The underlying logic is that applications that share information to be consumed by the networks while preserving the application-specific data privacy together with networks that are prepared in advance with applications flow treatment requirements will select and thus enable the appropriate means to offer the differentiated forwarding and traffic management behaviors matching those requirements while preserving data encryption practices end-to-end. Applications can be designed to separate the protection of the data that is intended to be consumed by involved networks and the one that is exclusively restricted to the application remote endpoint(s). Typical requirements clauses are described in Boucadair, Jacquenet & Wang (2014).