Application Enabled Open Networking Use Cases
draft-eckel-aeon-use-cases-00

Abstract

This document describes application enabled open networking use cases. Application enabled open networking (AEON) is a framework in which applications explicitly signal their flow characteristics to the network. This provides network nodes with visibility of the application flow characteristics, which enables them to apply the correct flow treatment and provide feedback to applications.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on July 12, 2014.

Copyright Notice

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Use Cases
• 2.1. Traffic Prioritization: Consistent experience of video conferencing with competing traffic
• 2.1.1. Description of Problem
• 2.1.2. Proposed Solution
• 2.1.3. User Benefit
• 2.1.4. Operator Benefit
• 2.1.5. Flow characteristics provided by application
• 2.1.6. Action taken by network as result of receiving flow characteristics
• 2.1.7. Feedback provided by network
• 2.2. Firewall Traversal: Identification of new applications
• 2.2.1. Description of Problem
• 2.2.2. Proposed Solution
• 2.2.3. User Benefit
• 2.2.4. Operator Benefit
• 2.2.5. Flow characteristics provided by application
• 2.2.6. Action taken by firewall as result of receiving flow characteristics
• 2.2.7. Feedback provided by firewall
• 2.3. Load Balancing: Identification of application for better load balancing without solely relying on inspection techniques
• 2.3.1. Description of Problem
• 2.3.2. Proposed Solution
• 2.3.3. User Benefit
• 2.3.4. Operator Benefit
• 2.3.5. Flow characteristics provided by application
• 2.3.6. Action taken by network as result of receiving flow characteristics
• 2.3.7. Feedback provided by network
• 2.4. Scavenger class: Creation of a scavenger class. Use metadata to shift high-bandwidth, low priority traffic to off-peak hours
• 2.4.1. Description of Problem
• 2.4.2. Proposed Solution
• 2.4.3. User Benefit
• 2.4.4. Operator Benefit
• 2.4.5. Flow characteristics provided by application
• 2.4.6. Action taken by network as result of receiving flow characteristics
• 2.4.7. Feedback provided by network
• 2.5. Video Adaptation: Use client metadata to help video bit rate selection
• 2.5.1. Description of Problem
• 2.5.2. Proposed Solution
• 2.5.3. User Benefit
• 2.5.4. Operator Benefit
• 2.5.5. Flow characteristics provided by application
• 2.5.6. Action taken by network as result of receiving flow characteristics
• 2.5.7. Feedback provided by network
• 2.6. Mobile Host/App Metadata: Use metadata for troubleshooting and network planning
• 2.6.1. Description of Problem
• 2.6.2. User Benefit
• 2.6.3. Operator Benefit
• 2.6.4. Flow characteristics provided by application
• 2.6.5. Action taken by network as result of receiving flow characteristics
• 2.6.6. Feedback provided by network
• 2.7. Multi-interface selection: Use metadata to help interface selection or prioritization
• 2.7.1. Description of Problem
• 2.7.2. Proposed Solution
• 2.7.3. User Benefit
• 2.7.4. Operator Benefit
• 2.7.5. Flow characteristics provided by application
• 3. Acknowledgements
• 4. Informative References
• Authors' Addresses

1. Introduction

Identification and treatment of application flows are critical for the successful deployment and operation of applications based on a wide range of signaling protocols. Historically, this functionality has been accomplished to the extent possible using heuristics, which inspect and infer flow characteristics. Heuristics may be based on port ranges, IP subnetting, or deep packet inspection (DPI), e.g. application level gateway (ALG). Port based solutions suffer from port overloading and inconsistent port usage. IP subnetting solutions are error prone and result in network management hassle. DPI is computationally expensive and becomes a challenge with the wider adoption of encrypted signaling and secured traffic. An additional drawback of DPI is that the resulting insights are not available, or need to be recomputed, at network nodes further down the application flow path.

Application enabled open networking (AEON) allows applications to explicitly signal their flow characteristics to the network. This provides network nodes with visibility of the application flow characteristics. These network nodes may take action based on this visibility and/or contribute to the flow description. The resulting flow description may be communicated as feedback from the network to applications.

This document describes a set of use cases addressable by AEON. Additional details on the AEON are provided in [I-D.eckert-intarea-flow-metadata-framework]

2. Use Cases

The following use cases have been identified.

1. Traffic Prioritization: Consistent experience of video conferencing with competing traffic.
2. Firewall Traversal: Identification of new applications.
3. Load Balancing: Identification of application for better load balancing without solely relying on inspection techniques.
4. Scavenger class: Creation of a scavenger class. Use metadata to shift high-bandwidth, low priority traffic to off-peak hours. TODO: That drifts from a use-case to a solution ("use metadata to ..."). Also, it appears to mix two things: (a) scavenger class and (b) time-shifting traffic. This is confusing.
5. Video Adaptation: Use client metadata to help video bit rate selection.
6. Mobile Host/App Metadata: Use metadata for troubleshooting and network planning.
7. Multi-interface selection: Use metadata to help interface selection or prioritization.

In describing each use case, the following information is provided.

• description of the problem
• proposed solution
• user benefit
• operator benefit
• flow characteristics provided by application
• action taken by network as result of receiving flow characteristics
• feedback provided by network

2.1. Traffic Prioritization: Consistent experience of video conferencing with competing traffic

2.1.1. Description of Problem

2.1.2. Proposed Solution

2.1.3. User Benefit

2.1.4. Operator Benefit

2.1.5. Flow characteristics provided by application

2.1.6. Action taken by network as result of receiving flow characteristics

2.1.7. Feedback provided by network

2.2. Firewall Traversal: Identification of new applications

2.2.1. Description of Problem

Modern firewalls use application-layer gateways (ALGs) to perform policy enforcement. For example firewalls implement SIP-aware Application Layer Gateway function, which examines the SIP signaling and opens the appropriate pinholes for the RTP media. In particular firewall extracts media transport addresses, transport protocol and ports from session description and creates a dynamic mapping for media to flow through. This model will not work in the following cases:

1. Session signaling is end-to-end encrypted (say, using TLS).
2. Firewall does not understand the session signaling protocol, or extensions to the protocol, used by the endpoints (e.g. WebRTC signaling protocols).
3. Session signaling and media traverse different firewalls (e.g., signaling exits a network via one firewall whereas media exits a network via a different firewall).

Enterprise networks that use firewalls with restrictive policies block new applications like WebRTC and delay deployment of killer applications.

2.2.2. Proposed Solution

The above problems can be addressed by the host getting authorization from the Application Server trusted by the network in order to install flows and associated actions (e.g., policies). PCP third party authorization (draft-wing-pcp-third-party-authz-01) solves this problem by associating the media session with the signaling session. This is done by sending a cryptographic token in the signaling which authorizes the firewall mapping for the media session.

2.2.3. User Benefit

Enterprise networks that use firewalls with restrictive policies can deploy new applications at a faster rate for user benefit.

2.2.4. Operator Benefit

Enterprise firewalls can enforce restrictive policies without the need to be enhanced to perform ALG on new applications. For example Enterprise firewall could have granular policies to permit peer-to-peer UDP media session only when the call is initiated using the selected WebRTC server (Dr. Good) it trusts and block others (Dr. Evil). PCP-aware firewalls can enforce such granular security policies without performing ALG on the session signaling protocols. This mechanism can be used by any other Application Function trusted by the network to permit time-bound, encrypted, peer-to-peer traffic.

2.2.5. Flow characteristics provided by application

The client requests dynamic mappings to permit flows required by the application. This request includes a cryptographic token and characteristics of the flow, such as the anticipated bandwidth needs as well as the tolerance to delay, loss, and jitter.

2.2.6. Action taken by firewall as result of receiving flow characteristics

The firewall uses the client request to permit and prioritize the traffic associated with those flows. The cryptographic token provides authorization for the flows and their prioritization.

2.2.7. Feedback provided by firewall

Firewall matches the authorization data with what is requested in the request sent by the client. If the authorization sets match, the firewall processes the request made by the client. If the token is invalid or the request exceeds what is authorized by the token then firewall rejects the request.

2.3. Load Balancing: Identification of application for better load balancing without solely relying on inspection techniques

2.3.1. Description of Problem

2.3.2. Proposed Solution

2.3.3. User Benefit

2.3.4. Operator Benefit

2.3.5. Flow characteristics provided by application

2.3.6. Action taken by network as result of receiving flow characteristics

2.3.7. Feedback provided by network

2.4. Scavenger class: Creation of a scavenger class. Use metadata to shift high-bandwidth, low priority traffic to off-peak hours

2.4.1. Description of Problem

2.4.2. Proposed Solution

2.4.3. User Benefit

2.4.4. Operator Benefit

2.4.5. Flow characteristics provided by application

2.4.6. Action taken by network as result of receiving flow characteristics

2.4.7. Feedback provided by network

2.5. Video Adaptation: Use client metadata to help video bit rate selection

HTTP Adaptive Streaming (HAS) is an umbrella term for various HTTP-based streaming technologies that allow a client to adaptively switch between multiple bitrates, depending on current network conditions. HAS client first requests and receives a Manifest File, and then, after parsing the information in the Manifest File, proceeds with sequentially requesting the chunks listed in the Manifest File.

2.5.1. Description of Problem

The problems with HAS are:

• HAS client selects the initial bitrate without knowing the current network conditions which could cause start-up delay and frame freezes while a lower bitrate chunk is being retrieved. HAS client does not have a mechanism to signal the flow characteristics and flow priority to the network.
• HAS server can mark the packets appropriately but setting DSCP has limitations. DSCP value may not be preserved or honored over the Internet and OS may not allow to set DSCP values.
• Content Providers may have agreements with ISPs and need a mechanism to convey the flow characteristics and flow priority to the ISP. Existing mechanisms and the associated limitations are:
  1. ISP can be configured with the IP addresses of content providers to prioritize the traffic originating from those servers. The limitations with this approach are ISP has to keep track of content providers IP addresses. With CDNI (Content Delivery Network InterConnection) content could be served either from uCDN (upstream CDN) or any of a number of dCDNs (downstream CDN) and it will not be possible to manually track the IP addresses of all the CDN surrogates. There is also no way to differentiate content which could be available in different bitrates.
  2. If HAS client is behind NAT and content provider uses RESTful API (OneAPI) to install differentiated QoS then ISP will struggle to find the pre-NAT information. Content provider also needs to be aware of the ISP to which the client is attached and the IP address of the Policy Decision Point (PDP) in the ISP to which it needs to signal the flow characteristics.
• ISP can use DPI to prioritize one-way video streaming content but is expensive and fails if the traffic is encrypted.

2.5.2. Proposed Solution

If ISP has agreement with content provider then HAS client can use third party authorization to request network resources. At a high level, this authorization works by the client first obtaining a cryptographic token from the authorizing network element, then including that token in the request along with relevant flow characteristics. ISP validates the token and grants the request.

2.5.3. User Benefit

AEON helps increase the average play quality, reduces the start-up delay and frame freezes by avoiding attempt to retrieve a too high-bit rate chunk etc thus improving the quality of experience for end user.

2.5.4. Operator Benefit

Network Operators can recognize and prioritize one-way video streaming content.

2.5.5. Flow characteristics provided by application

HAS client signals the flow characteristics such as the anticipated bandwidth needs as well as the tolerance to delay, loss, and jitter.

2.5.6. Action taken by network as result of receiving flow characteristics

Subject to local policies, a network node might perform bandwidth counting, or reconfigure the underlying network so that additional bandwidth is made available for this particular flow, or might perform other actions.

2.5.7. Feedback provided by network

The network responds that the client request can be fully or partially accommodated. It also notifies the client when conditions change.

2.6. Mobile Host/App Metadata: Use metadata for troubleshooting and network planning

2.6.1. Description of Problem

2.6.2. User Benefit

2.6.3. Operator Benefit

2.6.4. Flow characteristics provided by application

2.6.5. Action taken by network as result of receiving flow characteristics

2.6.6. Feedback provided by network

2.7. Multi-interface selection: Use metadata to help interface selection or prioritization

2.7.1. Description of Problem

An increasing number of hosts are operating in multiple-interface environments and a host with multiple interfaces needs to choose the best interface for communication. Oftentimes, this decision is based on a static configuration and does not consider the link characteristics of that interface, which may affect the user experience. The network interfaces may have different link characteristics, but that will not be known without the awareness of the upstream and downstream characteristics of the access link.

2.7.2. Proposed Solution

TODO

2.7.3. User Benefit

Applications can choose the best interface for communication using AEON.

2.7.4. Operator Benefit

The network that can provide the requested flow characteristics will be selected by the application thus increasing the subscriber base of the operator.

2.7.5. Flow characteristics provided by application

Application signals flow characteristics over multiple interfaces and based on the response from its various interfaces sorts the source addresses according to the link capacity characteristics. Source addresses from the interface which best fulfills the desired flow characteristics are assigned the highest priority and would be tried first to communicate with the server or remote peer. For example draft-reddy-mmusic-ice-best-interface-pcp-00 explains the mechanism where Interactive Connectivity Establishment (ICE) agent on a host with multiple interfaces uses AEON to determine the link characteristics of the host's interfaces, which influences the ICE candidate priority. Similarly draft-wing-mptcp-pcp-00 explains how Multipath TCP (MPTCP) can select the best path when multiple paths are available.

3. Acknowledgements

The authors thank the attendees of the Bar BoF for contributing towards this set of use cases.

4. Informative References

Authors' Addresses