Application Enabled Collaborative Networking: Problem Statement and Requirements

Networks today, whether public or private, are challenged with demands to support rapidly increasing amounts of traffic. New channels for creating and consuming rich media are deployed at a rapid pace. Pervasive video and access on demand are becoming second nature to consumers. Communication applications make extensive use of rich media, placing unprecedented quality of experience expectation on the underlying network. These trends present challenges for network forecast and planning operations. Now more so than ever before, identification and treatment of application flows are critical for the successful deployment and operation of a growing number of business and household applications. These applications are based on wide range of signaling protocols and deployed by a diverse set of application providers that is not necessarily affiliated with the network providers across which the applications are used. Historically, identification of application flows has been accomplished using heuristics, which infer flow characteristics based on port ranges, network separation, or inspection of the flow itself. Inspection techniques include DPI, which matches against characteristic signatures (e.g. key string, binary sequence, etc.) and DFI, which analyzes statistical characteristics and connection behavior of flows. Each of these techniques suffers from a set of limitations, particularly in the face of the challenges on the network 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 subnetting 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 are not available, or need to be recomputed, at network nodes further down the application flow path. As the IETF establishes default behaviors that thwart pervasive surveillance (e.g. ), it will be important to provide mechanisms for applications that want to have the network provide differential flow treatment for their data. The intent is to have applications protect the contents of their flows, yet have the ability to opt-in to information exchanges that provide a more precise allocation of network resources and thus a better user experience.

Various heuristic based approaches are used prevalently and successfully for the following workflows: Provide network operators with visibility of traffic usage and patterns for troubleshooting, capacity planning, and other off network workflows. This is done by exporting observed traffic analysis via standard protocols such as IPFIX and SNMP as well as by proprietary protocols and methods. Provide network operators with visibility of application and data usage for accounting and billing. Provide differentiated network services for specific traffic according to network operator defined policies, including traffic classification, policing and shaping (e.g. ), providing admission control (e.g. ), impacting routing, and permitting passage of specific traffic (e.g. firewall functions).

These typical workflows, visibility and differentiated network services, are critical in many networks. However, their reliance on inspection and observation limits the ability to enable these workflows more widely. Reasons for this include the following: Identification based on IP address lists is difficult to manage. The addresses may be numerous and may change, or they may be dynamic, private, or otherwise not meant to be exposed. With Content Delivery Network InterConnection (CDNI) , content could be served either from an upstream CDN (uCDN) or any of a number of downstream CDNs (dCDN), and it will not be possible to manually track the IP addresses of all the CDN surrogates. Even in cases where identification by IP addresses is possible, more granular identification of individual flows is not possible (e.g. audio vs. video vs. data). Classification based on TCP/UDP port numbers often result in incorrect results due to port overloading (i.e. ports used by applications other than those claiming the port with IANA). More and more traffic is encrypted, rendering DPI and DFI impossible, inefficient, or much more complex, and sometimes at the expense of privacy or security (e.g. need to share encryption keys with intermediary proxy performing DPI/DFI). Visibility generally requires inspecting the signaling traffic of applications. This traffic may flow through a different network path than the actual application data traffic. Impacting the traffic behavior is ineffective in those scenarios. Extensions to signaling protocols and changes in the ways application use them can result in false negatives or false positives during inspection. Inspection techniques are completely non-standard, so the ability and accuracy to identify traffic varies across vendors, and different implementation are likely to give different results for the same traffic. Inspection techniques that require parsing the payload of packets (e.g. DPI) impact performance due to additional processing, and impact memory due to the growing number and size of signatures to identify new protocols. Network services leveraging heuristic based classification impact the application behavior by impacting its traffic, but they do not provide explicit feedback to the application. This results in a lost opportunity for the application to gain insight and adjust its operation accordingly.

The IETF has standardized several mechanisms involving explicit signaling between applications and the network that may be used to support visibility and differentiated network services workflows. Unfortunately, none of these has experienced widespread deployment success, nor are they well suited for the applications usages described previously. Existing signaling options include the following: RSVP is the original on-path signaling protocol standardized by the IETF. It is transported out-of-band and could be used to signal information about any transport protocol traffic (it currently supports TCP and UDP). Its original goal was to provide admission control. Its requirement for explicit reservation of resources end to end proved too heavy for most network environments. Its success was further impacted by its reliance on router-alert, which often leads to RSVP packets being filtered by intervening networks, and by its requirement for access to a raw socket, something that is generally not available to applications running in user space. To date, more lightweight signaling workflows utilizing RSVP have not been standardized within the IETF. NSIS (next Steps in Signaling) is the next iteration of RSVP-like signaling defined by the IETF. It focused on the same fundamental workflow as RSVP admission control as its main driver, and because it did not provide significant enough use-case benefits over RSVP, it has seen even less adoption than RSVP. DiffServ and VAN Tagging style packet marking can help provide QoS in some environments, but such markings are often modified or removed at various points in the network or when crossing network boundaries. There are additional limitations when using DiffServ with real-time communications applications, and the DART working group has been chartered to write a document that explains the limitations that exist with DiffServ when used with RTP in general as well in the specific RTCWeb use cases .

Not surprisingly, there are several evolving proposals that aim to address the visibility and differentiated network services workflows where existing approaches are not sufficient. Protocol specific extensions are being defined, creating duplicate or inconsistent information models. This results operational complexity and a need to convert information between protocols to leverage the best protocol option for each specific use case. Examples of evolving signaling options include the following: STUN is an on-path, in-band signaling protocol that could be extended to provide signaling to on-path network devices. It provides an easily inspected packet signature, at least for transport protocols such as UDP. Through its extensions TURN and ICE , it is becoming prevalent in application signaling driven by the initial use-case of providing NAT and firewall traversal capabilities and detecting local and remote candidates for peer-to-peer media sessions. The TRAM working group is chartered to update TURN and STUN to make them more suitable for WebRTC. Port Control Protocol (PCP) provides a mechanism to describe a flow to the network. The primary driver for PCP is creating port mappings on NAT and firewall devices. When doing this, PCP pushes flow information from the host into the network (specifically to the network's NAT or firewall device), and receives information back from the network (from the NAT or firewall device). It is not meant to be used end-to-end but rather independently on one "edge" of a flow. It is therefore an attractive alternative because it allows the introduction of application to network signaling without relying on the remote peer. This is especially useful in multi-domain communications. RESTCONF is a REST-like protocol that provides a programmatic interface over HTTP for accessing data defined in YANG, using the datastores defined in NETCONF . It is meant to provide a standard mechanism for web applications to access the configuration data, operational data, data-model specific protocol operations, and notification events within a networking device, in a modular and extensible manner. Interface to the Routing System (I2RS) is a working group chartered to provide interfaces for management applications, network controllers, and user applications to make specific demands on the network. Abstraction and Control of Transport Networks (ACTN) is a non-working group mailing list intended to enable discussion of the architecture, use-cases, and requirements that provide abstraction and virtual control of transport networks to various applications/clients. Prefix coloring has been proposed for use in HOMENET and 6MAN working groups to provide differentiated services to applications based on IP address. RTP Media Congestion Avoidance Techniques (RMCAT) has been chartered to address the lack of generally accepted congestion control mechanisms for interactive real-time media, which is often carried via sets of flows using RTP over UDP. Explicit exchanges of flow characteristics and congestion information between applications and the network could play an important role in such mechanisms. Transport Services (TAPS) is an effort to create a working group to define transport services that are exposed to internet applications. A TAP enabled application identifies its needs of the locally available transports services via an API. Some of the information provided is the same as what AEON proposes to have the application communicate to the network. Furthermore, the transport services of TAPS could benefit from this communication with the network. Service Function Chaining (SFC) is a working group chartered to address issues associated with the deployment of service functions (e.g. firewalls, load balancers) in large-scale environments. Service function chaining is the definition and instantiation of an ordered set of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions. Flow characteristics communicated via AEON could be used as input into an SFC classifier and it could be transported as SFC metadata.

Rather than encourage independent, protocol specific solutions to this problem, this document advocates a protocol and application independent information model and individual data models that can be applied in a consistent fashion across a variety of protocols to enable explicit communication between applications and the networks on which they are used. The requirements are: Allow applications to explicitly signal their flow characteristics to the network. Provide network nodes visibility to application flow characteristics. Enable network nodes to contribute to application flow descriptions. Allow applications to receive resulting flow descriptions as feedback from the network. Complement existing heuristic based mechanisms. Provide differentiated service for both directions of a flow, including flows that cross administrative boundaries. Provide mechanism to authenticate and authorize endpoints/applications to signal flow characteristics, including 3rd party authentication and authorization for over-the-top (OTT) applications. Provide mechanism for integrity protection and replay protection of messages exchanged between the application and the network.

The authors thank Toerless Eckert, Reinaldo Penno, Dan Wing, Amine Choukir, Paul Jones, and Bill VerSteeg for their contributions to this document.