Application-Enabled Collaborative Networking

Introduction

Networks today, whether public or private, are challenged by demands to support rapidly increasing amounts of traffic. New channels for originating and consuming rich media are deployed at a rapid pace. Pervasive video and access on demand are becoming second nature to consumers. Applications make extensive use of rich media, placing unprecedented quality of experience (QoE) demands on the underlying network. These trends present challenges for network forecast and planning operations.

Now more so than ever before, identification and differential treatment of flows are critical for the successful deployment and operation of applications. 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.

Historically, identification of application flows has been accomplished using heuristics that infer flow characteristics based on port ranges, network separation, or inspection of the flow itself. Inspection techniques include:

• •

  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 Enabled Collaborative Networking (AECN) 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 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. The underlying logic is that a network that is prepared in advance with applications flow treatment requirements will select and enable the appropriate means to offer the differentiated forwarding and traffic management behaviors matching those requirements. Typical requirements clauses are described in Boucadair, M., Jacquenet, C. & Wang., N. (2014).

Background

Evidently, media bandwidth requirements always depend on the service being used. Common services like e-mail require less bandwidth. By contrast, other services such as cloud-hosted virtualized desktops can place heavy per-user demands on an Internet connection, especially in deployments with high resolution desktops or multimedia. Some tasks can be highly variable. Cloud storage services, whether straightforward file sharing such as Box and Dropbox or more complex document management such as SharePoint, end up using a variable amount of bandwidth. Photographs and video files can be huge and uploading these resources could consume a fair amount of the available bandwidth, creating problems like congestion, especially problematic on shared connection. Perhaps the biggest consumer of bandwidth in recent times has been the use of real time video and audio over the Internet.

On top of bandwidth, latency considerations are also very important. Some applications, such as e-mail, are latency insensitive. Real-time applications require small latencies. For example voice over IP (VoIP) applications become unusable in the presence of high end-to-end latency; even short delays of a few tens of milliseconds are enough to make a poor audio experience while hundreds of milliseconds can render them almost unlistenable, with 150 milliseconds generally regarded as the limit for tolerable voice calls.