< draft-conet-aeon-use-cases-00.txt		draft-conet-aeon-use-cases-01.txt >
	Internet Engineering Task Force W. George		Internet Engineering Task Force W. George
	Internet-Draft Time Warner Cable		Internet-Draft Time Warner Cable
	Intended status: Informational P. Fan		Intended status: Informational P. Fan
	Expires: November 30, 2014 China Mobile		Expires: January 5, 2015 China Mobile
			S. Matsushima
			SoftBank Telecom
	T. Reddy		T. Reddy
	C. Eckel		C. Eckel
	Cisco Systems, Inc.		Cisco Systems, Inc.
	May 29, 2014		July 4, 2014
	Application Enabled Collaborative Networking Use Cases		Application Enabled Collaborative Networking Use Cases
	draft-conet-aeon-use-cases-00		draft-conet-aeon-use-cases-01
	Abstract		Abstract
	This document describes application enabled collaborative networking		This document describes application enabled collaborative networking
	use cases. Application enabled collaborative networking has		use cases. Application enabled collaborative networking has
	applications explicitly signal their flow characteristics to the		applications explicitly signal their flow characteristics to the
	network. This provides network nodes with visibility of the		network. This provides network nodes with visibility of the
	application flow characteristics, which enables them to apply the		application flow characteristics, which enables them to apply the
	correct flow treatment and provide feedback to applications.		correct flow treatment and provide feedback to applications.
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 41 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 30, 2014.		This Internet-Draft will expire on January 5, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Firewall Traversal: Identification of new applications . 5		2.1. Firewall Traversal: Identification of new applications . 5
	2.1.1. Description of Problem . . . . . . . . . . . . . . . 5		2.1.1. Description of Problem . . . . . . . . . . . . . . . 5
	2.1.2. Proposed Solution . . . . . . . . . . . . . . . . . . 6		2.1.2. Proposed Solution . . . . . . . . . . . . . . . . . . 5
	2.1.3. User Benefit . . . . . . . . . . . . . . . . . . . . 6		2.1.3. User/Application Benefit . . . . . . . . . . . . . . 6
	2.1.4. Operator Benefit . . . . . . . . . . . . . . . . . . 6		2.1.4. Operator Benefit . . . . . . . . . . . . . . . . . . 6
	2.1.5. Application Benefit . . . . . . . . . . . . . . . . . 6		2.1.5. Flow characteristics provided by application . . . . 6
	2.1.6. Flow characteristics provided by application . . . . 6		2.1.6. Action taken by firewall as result of receiving flow
	2.1.7. Action taken by firewall as result of receiving flow		characteristics . . . . . . . . . . . . . . . . . . . 6
	characteristics . . . . . . . . . . . . . . . . . . . 7		2.1.7. Feedback provided by firewall . . . . . . . . . . . . 6
	2.1.8. Feedback provided by firewall . . . . . . . . . . . . 7		2.1.8. Security and Privacy Considerations . . . . . . . . . 6
	2.1.9. Security and Privacy Considerations . . . . . . . . . 7		2.2. Efficient Capacity Usage . . . . . . . . . . . . . . . . 6
	2.2. Efficient Capacity Usage . . . . . . . . . . . . . . . . 7		2.2.1. Description of Problem . . . . . . . . . . . . . . . 6
	2.2.1. Description of Problem . . . . . . . . . . . . . . . 7
	2.2.2. Proposed Solution . . . . . . . . . . . . . . . . . . 8		2.2.2. Proposed Solution . . . . . . . . . . . . . . . . . . 8
	2.2.3. User Benefit . . . . . . . . . . . . . . . . . . . . 9		2.2.3. User/Application Benefit . . . . . . . . . . . . . . 9
	2.2.4. Operator Benefit . . . . . . . . . . . . . . . . . . 9		2.2.4. Operator Benefit . . . . . . . . . . . . . . . . . . 9
	2.2.5. Application Benefit . . . . . . . . . . . . . . . . . 9		2.2.5. Flow characteristics provided by application . . . . 9
	2.2.6. Flow characteristics provided by application . . . . 9		2.2.6. Action taken by network as result of receiving flow
	2.2.7. Action taken by network as result of receiving flow		characteristics . . . . . . . . . . . . . . . . . . . 9
	characteristics . . . . . . . . . . . . . . . . . . . 10		2.2.7. Feedback provided by network . . . . . . . . . . . . 9
	2.2.8. Feedback provided by network . . . . . . . . . . . . 10		2.2.8. Security and Privacy Considerations . . . . . . . . . 10
	2.2.9. Security and Privacy Considerations . . . . . . . . . 10		2.3. Video Adaptation . . . . . . . . . . . . . . . . . . . . 10
	2.3. Video Adaptation: Use client metadata to help video bit		2.3.1. Description of Problem . . . . . . . . . . . . . . . 10
	rate selection . . . . . . . . . . . . . . . . . . . . . 10
	2.3.1. Description of Problem . . . . . . . . . . . . . . . 11
	2.3.2. Proposed Solution . . . . . . . . . . . . . . . . . . 11		2.3.2. Proposed Solution . . . . . . . . . . . . . . . . . . 11
	2.3.3. User Benefit . . . . . . . . . . . . . . . . . . . . 12		2.3.3. User/Application Benefit . . . . . . . . . . . . . . 11
	2.3.4. Operator Benefit . . . . . . . . . . . . . . . . . . 12		2.3.4. Operator Benefit . . . . . . . . . . . . . . . . . . 11
	2.3.5. Application Benefit . . . . . . . . . . . . . . . . . 12		2.3.5. Flow characteristics provided by application . . . . 11
	2.3.6. Flow characteristics provided by application . . . . 12		2.3.6. Action taken by network as result of receiving flow
	2.3.7. Action taken by network as result of receiving flow
	characteristics . . . . . . . . . . . . . . . . . . . 12		characteristics . . . . . . . . . . . . . . . . . . . 12
	2.3.8. Feedback provided by network . . . . . . . . . . . . 12		2.3.7. Feedback provided by network . . . . . . . . . . . . 12
	2.3.9. Security and Privacy Considerations . . . . . . . . . 12		2.3.8. Security and Privacy Considerations . . . . . . . . . 12
	2.4. Multi-interface selection: Use metadata to help interface		2.4. Multi-interface selection: Use metadata to help interface
	selection or prioritization . . . . . . . . . . . . . . . 12		selection or prioritization . . . . . . . . . . . . . . . 12
	2.4.1. Description of Problem . . . . . . . . . . . . . . . 12		2.4.1. Description of Problem . . . . . . . . . . . . . . . 12
	2.4.2. Proposed Solution . . . . . . . . . . . . . . . . . . 13		2.4.2. Proposed Solution . . . . . . . . . . . . . . . . . . 12
	2.4.3. User Benefit . . . . . . . . . . . . . . . . . . . . 13		2.4.3. User/Application Benefit . . . . . . . . . . . . . . 12
	2.4.4. Operator Benefit . . . . . . . . . . . . . . . . . . 13		2.4.4. Operator Benefit . . . . . . . . . . . . . . . . . . 13
	2.4.5. Application Benefit . . . . . . . . . . . . . . . . . 13		2.4.5. Flow characteristics provided by application . . . . 13
	2.4.6. Flow characteristics provided by application . . . . 13		2.4.6. Action taken by network as result of receiving flow
	2.4.7. Action taken by network as result of receiving flow
	characteristics . . . . . . . . . . . . . . . . . . . 13		characteristics . . . . . . . . . . . . . . . . . . . 13
	2.4.8. Feedback provided by network . . . . . . . . . . . . 13		2.4.7. Feedback provided by network . . . . . . . . . . . . 13
	2.4.9. Security and Privacy Considerations . . . . . . . . . 13		2.4.8. Security and Privacy Considerations . . . . . . . . . 13
	2.5. Session Identification: Identification of multiple media		2.5. Session Identification: Identification of multiple media
	flows belonging to a common application session . . . . . 13		flows belonging to a common application session . . . . . 13
	2.5.1. Description of Problem . . . . . . . . . . . . . . . 13		2.5.1. Description of Problem . . . . . . . . . . . . . . . 13
	2.5.2. Proposed Solution . . . . . . . . . . . . . . . . . . 14		2.5.2. Proposed Solution . . . . . . . . . . . . . . . . . . 14
	2.5.3. User Benefit . . . . . . . . . . . . . . . . . . . . 14		2.5.3. User/Application Benefit . . . . . . . . . . . . . . 14
	2.5.4. Operator Benefit . . . . . . . . . . . . . . . . . . 14		2.5.4. Operator Benefit . . . . . . . . . . . . . . . . . . 14
	2.5.5. Application Benefit . . . . . . . . . . . . . . . . . 14		2.5.5. Flow characteristics provided by application . . . . 14
	2.5.6. Flow characteristics provided by application . . . . 14		2.5.6. Action taken by network as result of receiving flow
	2.5.7. Action taken by network as result of receiving flow
	characteristics . . . . . . . . . . . . . . . . . . . 15		characteristics . . . . . . . . . . . . . . . . . . . 15
	2.5.8. Feedback provided by network . . . . . . . . . . . . 15		2.5.7. Feedback provided by network . . . . . . . . . . . . 15
	2.5.9. Security and Privacy Considerations . . . . . . . . . 15		2.5.8. Security and Privacy Considerations . . . . . . . . . 15
	2.6. Content Based Charging . . . . . . . . . . . . . . . . . 15		2.6. Content Based Charging . . . . . . . . . . . . . . . . . 15
	2.6.1. Description of Problem . . . . . . . . . . . . . . . 15		2.6.1. Description of Problem . . . . . . . . . . . . . . . 15
	2.6.2. Proposed Solution . . . . . . . . . . . . . . . . . . 15		2.6.2. Proposed Solution . . . . . . . . . . . . . . . . . . 15
	2.6.3. User Benefit . . . . . . . . . . . . . . . . . . . . 16		2.6.3. User/Application Benefit . . . . . . . . . . . . . . 16
	2.6.4. Operator Benefit . . . . . . . . . . . . . . . . . . 16		2.6.4. Operator Benefit . . . . . . . . . . . . . . . . . . 16
	2.6.5. Application Benefit . . . . . . . . . . . . . . . . . 16		2.6.5. Flow characteristics provided by application . . . . 16
	2.6.6. Flow characteristics provided by application . . . . 16		2.6.6. Action taken by network as result of receiving flow
	2.6.7. Action taken by network as result of receiving flow
	characteristics . . . . . . . . . . . . . . . . . . . 16		characteristics . . . . . . . . . . . . . . . . . . . 16
	2.6.8. Feedback provided by network . . . . . . . . . . . . 17		2.6.7. Feedback provided by network . . . . . . . . . . . . 16
	2.6.9. Security and Privacy Considerations . . . . . . . . . 17		2.6.8. Security and Privacy Considerations . . . . . . . . . 16
	2.7. Open QoS and Experience Enhancement for Applications . . 17		3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
	2.7.1. Description of Problem . . . . . . . . . . . . . . . 17		4. Informative References . . . . . . . . . . . . . . . . . . . 17
	2.7.2. Proposed Solution . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	2.7.3. User Benefit . . . . . . . . . . . . . . . . . . . . 18
	2.7.4. Operator Benefit . . . . . . . . . . . . . . . . . . 18
	2.7.5. Application Benefit . . . . . . . . . . . . . . . . . 18
	2.7.6. Flow characteristics provided by application . . . . 18
	2.7.7. Action taken by network as result of receiving flow
	characteristics . . . . . . . . . . . . . . . . . . . 18
	2.7.8. Feedback provided by network . . . . . . . . . . . . 18
	2.7.9. Security and Privacy Considerations . . . . . . . . . 19
	3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	Identification and treatment of application flows are important to		Identification and treatment of application flows are important to
	many application providers and network operators. They often rely on		many application providers and network operators. They often rely on
	these capabilities to deploy and/or support a wide range of		these capabilities to deploy and/or support a wide range of
	applications. These applications, and the packet flows they generate		applications. These applications, and the packet flows they generate
	and consume, may have specific connectivity requirements that can be		and consume, may require specific bandwidth, latency, etc., that can
	met if made known to the network. Historically, this functionality		be better met if made known to the network. Historically, this
	has been implemented to the extent possible using heuristics, which		functionality has been implemented to the extent possible using
	inspect and infer flow characteristics. Heuristics may be based on		heuristics, which inspect and infer flow characteristics. Heuristics
	port ranges, network separation (e.g. subnets or VLANs, Deep Flow		may be based on port ranges, network separation (e.g. subnets or
	Inspection (DFI), or Deep Packet Inspection (DPI). But many		VLANs, Deep Flow Inspection (DFI), or Deep Packet Inspection (DPI).
	application flows in current usages are dynamic, adaptive, time-		But many application flows in current usages are dynamic, adaptive,
	bound, encrypted, peer-to-peer, asymmetric, used on multipurpose		time-bound, encrypted, peer-to-peer, asymmetric, used on multipurpose
	devices, and have different priorities depending on direction of		devices, and have different priorities depending on direction of
	flow, user preferences, and other factors. Any combination of these		flow, user preferences, and other factors. Any combination of these
	properties renders heuristic based techniques less effective and may		properties renders heuristic based techniques less effective and may
	result in compromises to application security or user privacy, as		result in compromises to application security or user privacy, as
	described in detail in draft-conet-aeon-problem-statement-00.		described in detail in [I-D.conet-aeon-problem-statement].
	Application enabled collaborative networking allows applications to		Application enabled collaborative networking allows applications to
	explicitly signal their flow characteristics to the network. This		explicitly signal their flow characteristics to the network. This
	provides network nodes with visibility of the application flow		provides network nodes with visibility of the application flow
	characteristics. These network nodes may take action based on this		characteristics. These network nodes may take action based on this
	visibility and/or contribute to the flow description. The resulting		visibility and/or contribute to the flow description. The resulting
	flow description may be communicated as feedback from the network to		flow description may be communicated as feedback from the network to
	applications. This proposes a way of building collaborative		applications. This proposes a way of building collaborative
	connections for network operators and application providers,		connections for network operators and application providers,
	benefiting both of them as well as users. Network provider is able		benefiting both of them as well as users. Network provider is able
	skipping to change at page 4, line 49 ¶		skipping to change at page 4, line 31 ¶
	enabled collaborative networking.		enabled collaborative networking.
	2. Use Cases		2. Use Cases
	The following use cases have been identified.		The following use cases have been identified.
	1. Firewall Traversal: Identification of new applications		1. Firewall Traversal: Identification of new applications
	2. Efficient Capacity Usage		2. Efficient Capacity Usage
	3. Video Adaptation: Use client metadata to help video bit rate		3. Video Adaptation
	selection.
	4. Multi-interface selection: Use metadata to help interface		4. Multi-interface selection: Use metadata to help interface
	selection or prioritization.		selection or prioritization.
	5. Session Identification: Identification of multiple media flows		5. Session Identification: Identification of multiple media flows
	belonging to a common application session.		belonging to a common application session.
	6. Content Based Charging		6. Content Based Charging
	7. Open QoS and Experience Enhancement for Applications
	In describing each use case, the following information is provided.		In describing each use case, the following information is provided.
	o description of the problem		o description of the problem
	o proposed solution		o proposed solution
	o user benefit		o user/application benefit
	o operator benefit		o operator benefit
	o application benefit
	o flow characteristics provided by application		o flow characteristics provided by application
	o action taken by network as result of receiving flow		o action taken by network as result of receiving flow
	characteristics		characteristics
	o feedback provided by network		o feedback provided by network
	o security and privacy considerations		o security and privacy considerations
	2.1. Firewall Traversal: Identification of new applications		2.1. Firewall Traversal: Identification of new applications
	2.1.1. Description of Problem		2.1.1. Description of Problem
	skipping to change at page 6, line 19 ¶		skipping to change at page 5, line 40 ¶
	3. Session signaling and media traverse different firewalls (e.g.,		3. Session signaling and media traverse different firewalls (e.g.,
	signaling exits a network via one firewall whereas media exits a		signaling exits a network via one firewall whereas media exits a
	network via a different firewall).		network via a different firewall).
	Enterprise networks that use firewalls with restrictive policies		Enterprise networks that use firewalls with restrictive policies
	block new applications like WebRTC and delay deployment of killer		block new applications like WebRTC and delay deployment of killer
	applications.		applications.
	2.1.2. Proposed Solution		2.1.2. Proposed Solution
	The above problems can be addressed by the host getting authorization		These problems can be addressed by the host providing authorization
	from the Application Server trusted by the network in order to		it received from an application server that is trusted by the network
	install flows and associated actions (e.g., policies). PCP third		to authorize flows and associated actions (e.g., policies). PCP
	party authorization (draft-wing-pcp-third-party-authz-01) solves this		third party authorization ([I-D.wing-pcp-third-party-authz]) solves
	problem by associating the media session with the signaling session.		this problem by associating the media session with the signaling
	This is done by sending a cryptographic token in the signaling which		session. This is done by sending a cryptographic token in the
	authorizes the firewall mapping for the media session.		signaling which authorizes the firewall mapping for the media
			session.
	2.1.3. User Benefit		2.1.3. User/Application Benefit
	Enterprise networks that use firewalls with restrictive policies can		Enterprise networks that use firewalls with restrictive policies can
	deploy new applications at a faster rate for user benefit.		deploy new applications at a faster rate for user benefit.
	2.1.4. Operator Benefit		2.1.4. Operator Benefit
	Enterprise firewalls can enforce restrictive policies without the		Enterprise firewalls can enforce restrictive policies without the
	need to be enhanced to perform ALG on new applications. For example		need to be enhanced to perform ALG on new applications. For example
	Enterprise firewall could have granular policies to permit peer-to-		Enterprise firewall could have granular policies to permit peer-to-
	peer UDP media session only when the call is initiated using the		peer UDP media session only when the call is initiated using the
	selected WebRTC server (Dr. Good) it trusts and block others (Dr.		selected WebRTC server (Dr. Good) it trusts and block others (Dr.
	Evil). PCP-aware firewalls can enforce such granular security		Evil). PCP-aware firewalls can enforce such granular security
	policies without performing ALG on the session signaling protocols.		policies without performing ALG on the session signaling protocols.
	This mechanism can be used by any other Application Function trusted		This mechanism can be used by any other Application Function trusted
	by the network to permit time-bound, encrypted, peer-to-peer traffic.		by the network to permit time-bound, encrypted, peer-to-peer traffic.
	2.1.5. Application Benefit		2.1.5. Flow characteristics provided by application
	2.1.6. Flow characteristics provided by application
	The client requests dynamic mappings to permit flows required by the		The client requests dynamic mappings to permit flows required by the
	application. This request includes a cryptographic token and		application. This request includes a cryptographic token and
	characteristics of the flow, such as the anticipated bandwidth needs		characteristics of the flow, such as the anticipated bandwidth needs
	as well as the tolerance to delay, loss, and jitter.		as well as the tolerance to delay, loss, and jitter.
	2.1.7. Action taken by firewall as result of receiving flow		2.1.6. Action taken by firewall as result of receiving flow
	characteristics		characteristics
	The firewall uses the client request to permit and prioritize the		The firewall uses the client request to permit and prioritize the
	traffic associated with those flows. The cryptographic token		traffic associated with those flows. The cryptographic token
	provides authorization for the flows and their prioritization.		provides authorization for the flows and their prioritization.
	2.1.8. Feedback provided by firewall		2.1.7. Feedback provided by firewall
	Firewall matches the authorization data with what is requested in the		Firewall matches the authorization data with what is requested in the
	request sent by the client. If the authorization sets match, the		request sent by the client. If the authorization sets match, the
	firewall processes the request made by the client. If the token is		firewall processes the request made by the client. If the token is
	invalid or the request exceeds what is authorized by the token then		invalid or the request exceeds what is authorized by the token then
	firewall rejects the request.		firewall rejects the request.
	2.1.9. Security and Privacy Considerations		2.1.8. Security and Privacy Considerations
	2.2. Efficient Capacity Usage		2.2. Efficient Capacity Usage
	2.2.1. Description of Problem		2.2.1. Description of Problem
	Network traffic is bursty and often follows diurnal usage patterns		Network traffic is bursty and often follows diurnal usage patterns
	such that there are times of day where traffic levels are at a peak,		such that there are times of day where traffic levels are at a peak,
	and other times of day where they are at a valley. Networks that are		and other times of day where they are at a valley. Networks that are
	properly capacity planned need to have enough capacity to service the		properly capacity planned need to have enough capacity to service the
	traffic demands at peak. In a network with consistent demand and		traffic demands at peak. In a network with consistent demand and
	skipping to change at page 9, line 23 ¶		skipping to change at page 9, line 5 ¶
	This solution could also be used in conjunction with defined paths		This solution could also be used in conjunction with defined paths
	through the network (TE, Segment Routing, etc) to provide capacity		through the network (TE, Segment Routing, etc) to provide capacity
	for traffic that has specific performance requirements, or is not		for traffic that has specific performance requirements, or is not
	sensitive to using a sub-optimal path. i.e. capacity exists on this		sensitive to using a sub-optimal path. i.e. capacity exists on this
	backup path that is much longer, so since this traffic does not care		backup path that is much longer, so since this traffic does not care
	about a few 10s of milliseconds of additional latency, it should be		about a few 10s of milliseconds of additional latency, it should be
	marked to use the non-optimal path even if that path is not seen as		marked to use the non-optimal path even if that path is not seen as
	best by the routing protocol.		best by the routing protocol.
	2.2.3. User Benefit		2.2.3. User/Application Benefit
	Key user benefits include:		Key user benefits include:
	o Best service for real-time and other interactive applications		o Best service for real-time and other interactive applications
	(less interference from non real-time or non-interactive traffic)		(less interference from non real-time or non-interactive traffic)
	o More control over application bandwidth usage, potential for		o More control over application bandwidth usage, potential for
	service guarantees for important applications		service guarantees for important applications
	2.2.4. Operator Benefit		2.2.4. Operator Benefit
	Reduced cost via better/more efficient management of capacity/growth		Reduced cost via better/more efficient management of capacity/growth
	while still providing first-class service to customers.		while still providing first-class service to customers.
	2.2.5. Application Benefit		2.2.5. Flow characteristics provided by application
	2.2.6. Flow characteristics provided by application
	An application signals one or more of the following to the network:		An application signals one or more of the following to the network:
	o level of service required (e.g. guaranteed service, best-effort,		o level of service required (e.g. guaranteed service, best-effort,
	or below best effort)		or below best effort)
	o minimum requirement for transmission rate/throughput		o minimum requirement for transmission rate/throughput
	o that it is tolerant/intolerant of high latency, high jitter, high		o that it is tolerant/intolerant of high latency, high jitter, high
	packet loss		packet loss
	o a request in the form "I need to deliver this data by X, when		o a request in the form "I need to deliver this data by X, when
	should I send, and how should I identify the flow?"		should I send, and how should I identify the flow?"
	2.2.7. Action taken by network as result of receiving flow		2.2.6. Action taken by network as result of receiving flow
	characteristics		characteristics
	Potential action taken by the network include:		Potential action taken by the network include:
	o Identify path through network that meets flow service requirements		o Identify path through network that meets flow service requirements
	o Treat marked traffic according to identified service type (e.g.		o Treat marked traffic according to identified service type (e.g.
	scavenger class carried in periods of low usage, and/or dropped		scavenger class carried in periods of low usage, and/or dropped
	during congestion)		during congestion)
	2.2.8. Feedback provided by network		2.2.7. Feedback provided by network
	Feedback provided by the network includes:		Feedback provided by the network includes:
	o Peak demand times, either proactively (e.g. this network peaks		o Peak demand times, either proactively (e.g. this network peaks
	daily between the hours of X and Y) or reactively through		daily between the hours of X and Y) or reactively through
	something like Explicit Congestion Notification (this network is		something like Explicit Congestion Notification (this network is
	at peak or is experiencing congestion right now)		at peak or is experiencing congestion right now)
	o ACK/NACK for requested level of service, throughput, etc.		o ACK/NACK for requested level of service, throughput, etc.
	2.2.9. Security and Privacy Considerations		2.2.8. Security and Privacy Considerations
	This requires a trust model between application and network so that		This requires a trust model between application and network so that
	the information communicated about performance envelope requirements		the information communicated about performance envelope requirements
	can be trusted. In the case where there are different costs,		can be trusted. In the case where there are different costs,
	charging rates, tonnage limits by type of traffic, there is		charging rates, tonnage limits by type of traffic, there is
	opportunity for abuse (maliciously marking all traffic such that it		opportunity for abuse (maliciously marking all traffic such that it
	incurs additional cost, or such that it is dropped when it should not		incurs additional cost, or such that it is dropped when it should not
	be, etc). Even simpler data such as IP Precedence is often remarked		be, etc). Even simpler data such as IP Precedence is often remarked
	at the boundaries between networks as untrusted, so carrying this		at the boundaries between networks as untrusted, so carrying this
	sort of metadata likely requires a method to ensure that it was set		sort of metadata likely requires a method to ensure that it was set
	by a trusted entity and not manipulated in transit.		by a trusted entity and not manipulated in transit.
	2.3. Video Adaptation: Use client metadata to help video bit rate		2.3. Video Adaptation
	selection
	HTTP Adaptive Streaming (HAS) is an umbrella term for various HTTP-		HTTP Adaptive Streaming (HAS) is an umbrella term for various HTTP-
	based streaming technologies that allow a client to adaptively switch		based streaming technologies that allow a client to adaptively switch
	between multiple bitrates, depending on current network conditions.		between multiple bitrates, depending on current network conditions.
	HAS client first requests and receives a Manifest File, and then,		HAS client first requests and receives a Manifest File, and then,
	after parsing the information in the Manifest File, proceeds with		after parsing the information in the Manifest File, proceeds with
	sequentially requesting the chunks listed in the Manifest File.		sequentially requesting the chunks listed in the Manifest File.
	2.3.1. Description of Problem		2.3.1. Description of Problem
	The problems with HAS are:		The problems with HAS are:
	o HAS client selects the initial bitrate without knowing the current		o HAS client selects the initial bitrate without knowing the current
	network conditions which could cause start-up delay and frame		network conditions which could cause start-up delay and frame
	freezes while a lower bitrate chunk is being retrieved. HAS		freezes while a lower bitrate chunk is being retrieved. HAS
	client does not have a mechanism to signal the flow		client does not have a mechanism to signal the flow
	characteristics and flow priority to the network.		characteristics and desired treatment to the network.
	o HAS server can mark the packets appropriately but setting DSCP has		o HAS server can mark the packets appropriately but setting DSCP has
	limitations. DSCP value may not be preserved or honored over the		limitations. DSCP value may not be preserved or honored over the
	Internet and OS may not allow to set DSCP values.		Internet and operating system may not allow to set DSCP values.
	o Content Providers may have agreements with ISPs and need a		o Content Providers may need a mechanism to convey the flow
	mechanism to convey the flow characteristics and flow priority to		characteristics and desired treatment to the ISP. Existing
	the ISP. Existing mechanisms and the associated limitations are:		mechanisms and the associated limitations are:
	1. ISP can be configured with the IP addresses of content		1. ISP can be configured with the IP addresses of content
	providers to prioritize the traffic originating from those		providers to identify the traffic originating from those
	servers. The limitations with this approach are ISP has to		servers. The limitations with this approach are ISP has to
	keep track of content providers IP addresses. With CDNI		keep track of content providers IP addresses. With CDNI
	(Content Delivery Network InterConnection) content could be		(Content Delivery Network InterConnection) content could be
	served either from uCDN (upstream CDN) or any of a number of		served either from uCDN (upstream CDN) or any of a number of
	dCDNs (downstream CDN) and it will not be possible to manually		dCDNs (downstream CDN) and it will not be possible to manually
	track the IP addresses of all the CDN surrogates. There is		track the IP addresses of all the CDN surrogates. There is
	also no way to differentiate content which could be available		also no way to differentiate content which could be available
	in different bitrates.		in different bitrates.
	2. If HAS client is behind NAT and content provider uses RESTful		2. If HAS client is behind NAT and content provider uses RESTful
	API (OneAPI) to install differentiated QoS then ISP will		API (OneAPI) to install differentiated QoS then ISP will
	struggle to find the pre-NAT information. Content provider		struggle to find the pre-NAT information. Content provider
	also needs to be aware of the ISP to which the client is		also needs to be aware of the ISP to which the client is
	attached and the IP address of the Policy Decision Point (PDP)		attached and the IP address of the Policy Decision Point (PDP)
	in the ISP to which it needs to signal the flow		in the ISP to which it needs to signal the flow
	characteristics.		characteristics.
	o ISP can use DPI to prioritize one-way video streaming content but		o ISP can use DPI to identify one-way video streaming content but is
	is expensive and fails if the traffic is encrypted.		expensive and fails if the traffic is encrypted.
	2.3.2. Proposed Solution		2.3.2. Proposed Solution
	If ISP has agreement with content provider then HAS client can use		HAS client can use third party authorization to request network
	third party authorization to request network resources. At a high		resources. At a high level, this authorization works by the client
	level, this authorization works by the client first obtaining a		first obtaining a cryptographic token from the authorizing network
	cryptographic token from the authorizing network element, then		element, then including that token in the request along with relevant
	including that token in the request along with relevant flow		flow characteristics. ISP validates the token and grants the
	characteristics. ISP validates the token and grants the request.		request.
	2.3.3. User Benefit		2.3.3. User/Application Benefit
	AEON helps increase the average play quality, reduces the start-up		This solution helps increase the average play quality, reduces the
	delay and frame freezes by avoiding attempt to retrieve a too high-		start-up delay and frame freezes by avoiding attempt to retrieve a
	bit rate chunk etc thus improving the quality of experience for end		too high-bit rate chunk etc thus improving the quality of experience
	user.		for end user.
	2.3.4. Operator Benefit		2.3.4. Operator Benefit
	Network Operators can recognize and prioritize one-way video		Network operators can better recognize and treat one-way video
	streaming content.		streaming content.
	2.3.5. Application Benefit		2.3.5. Flow characteristics provided by application
	2.3.6. Flow characteristics provided by application
	HAS client signals the flow characteristics such as the anticipated		HAS client signals the flow characteristics such as the anticipated
	bandwidth needs as well as the tolerance to delay, loss, and jitter.		bandwidth needs as well as the tolerance to delay, loss, and jitter.
	2.3.7. Action taken by network as result of receiving flow		2.3.6. Action taken by network as result of receiving flow
	characteristics		characteristics
	Subject to local policies, a network node might perform bandwidth		Subject to local policies, a network node might perform bandwidth
	counting, or reconfigure the underlying network so that additional		counting, or reconfigure the underlying network so that additional
	bandwidth is made available for this particular flow, or might		bandwidth is made available for this particular flow, or might
	perform other actions.		perform other actions.
	2.3.8. Feedback provided by network		2.3.7. Feedback provided by network
	The network responds that the client request can be fully or		The network responds that the client request can be fully or
	partially accommodated. It also notifies the client when conditions		partially accommodated. It also notifies the client when conditions
	change.		change.
	2.3.9. Security and Privacy Considerations		2.3.8. Security and Privacy Considerations
	2.4. Multi-interface selection: Use metadata to help interface		2.4. Multi-interface selection: Use metadata to help interface
	selection or prioritization		selection or prioritization
	2.4.1. Description of Problem		2.4.1. Description of Problem
	An increasing number of hosts are operating in multiple-interface		An increasing number of hosts are operating in multiple-interface
	environments and a host with multiple interfaces needs to choose the		environments and a host with multiple interfaces needs to choose the
	best interface for communication. Oftentimes, this decision is based		best interface for communication. Oftentimes, this decision is based
	on a static configuration and does not consider the link		on a static configuration and does not consider the link
	characteristics of that interface, which may affect the user		characteristics of that interface, which may affect the user
	experience. The network interfaces may have different link		experience. The network interfaces may have different link
	characteristics, but that will not be known without the awareness of		characteristics, but that will not be known without the awareness of
	the upstream and downstream characteristics of the access link.		the upstream and downstream characteristics of the access link.
	2.4.2. Proposed Solution		2.4.2. Proposed Solution
	TODO		The problem can be solved if a mechanism is provided for the
			applications to communicate required flow characteristics with the
			available interfaces, and know about network condition of each
			interface, or to what extent application requirement of flow
			characteristics can be met by each interface. Application can then
			prioritize the interfaces based on information gathered and select
			one or more interfaces that best meet its requirement.
	2.4.3. User Benefit		2.4.3. User/Application Benefit
	Applications can choose the best interface for communication using		Applications can choose the interface that best meets their
	AEON.		requirements for communication. User experience is improved because
			of the consistency between flow characteristics requested by
			application and network ability provided by the selected interface.
	2.4.4. Operator Benefit		2.4.4. Operator Benefit
	The network that can provide the requested flow characteristics will		The network that can provide the requested flow characteristics will
	be selected by the application thus increasing the subscriber base of		be selected by the application thus increasing the subscriber base of
	the operator.		the operator.
	2.4.5. Application Benefit		2.4.5. Flow characteristics provided by application
	2.4.6. Flow characteristics provided by application
	Application signals flow characteristics over multiple interfaces and		Application signals flow characteristics over multiple interfaces and
	based on the response from its various interfaces sorts the source		based on the response from its various interfaces sorts the source
	addresses according to the link capacity characteristics. Source		addresses according to the link capacity characteristics. Source
	addresses from the interface which best fulfills the desired flow		addresses from the interface which best fulfills the desired flow
	characteristics are assigned the highest priority and would be tried		characteristics are assigned the highest priority and would be tried
	first to communicate with the server or remote peer. For example		first to communicate with the server or remote peer. For example
	draft-reddy-mmusic-ice-best-interface-pcp-00 explains the mechanism		[I-D.reddy-mmusic-ice-best-interface-pcp] explains the mechanism
	where Interactive Connectivity Establishment (ICE) agent on a host		where Interactive Connectivity Establishment (ICE) agent on a host
	with multiple interfaces uses AEON to determine the link		with multiple interfaces determines the link characteristics of the
	characteristics of the host's interfaces, which influences the ICE		host's interfaces, which influences the ICE candidate priority.
	candidate priority. Similarly draft-wing-mptcp-pcp-00 explains how		Similarly [I-D.wing-mptcp-pcp] explains how Multipath TCP (MPTCP) can
	Multipath TCP (MPTCP) can select the best path when multiple paths		select the best path when multiple paths are available.
	are available.
	2.4.7. Action taken by network as result of receiving flow		2.4.6. Action taken by network as result of receiving flow
	characteristics		characteristics
	2.4.8. Feedback provided by network		Network identifies flow characteristics requested by applications,
			and decides whether the request can be met or not.
	2.4.9. Security and Privacy Considerations		2.4.7. Feedback provided by network
			Link characteristics and ACK/NACK for flow requirement can be
			provided as feedback by network.
			2.4.8. Security and Privacy Considerations
			Users/applications are expected to consider security of interfaces,
			e.g. an untrusted public wifi access point will have lower priority
			than a trusted VPN tunnel, when prioritizing and selecting the
			interfaces.
	2.5. Session Identification: Identification of multiple media flows		2.5. Session Identification: Identification of multiple media flows
	belonging to a common application session		belonging to a common application session
	2.5.1. Description of Problem		2.5.1. Description of Problem
	Many end-to-end application sessions involve multiple application		Many end-to-end application sessions involve multiple application
	protocols, devices and administrative domains. These sessions		protocols, devices and administrative domains. These sessions
	involve multiple media flows (e.g. an audio flow and a video flow for		involve multiple media flows (e.g. an audio flow and a video flow for
	a video call, media flows between different entities in a		a video call, media flows between different entities in a
	supplementary service session consisting of multiple SIP dialogs or		supplementary service session consisting of multiple SIP dialogs or
	H.323 calls). Media flows may be added/removed from a application		H.323 calls). Media flows may be added/removed from a application
	session during the lifetime of the session. From within the network,		session during the lifetime of the session. From within the network,
	determining which media flows are associated with each application		determining which media flows are associated with each application
	session is often difficult, making it hard to provide application		session is often difficult, making it hard to provide application
	level troubleshooting, traffic analysis, and QoS.		level troubleshooting, traffic analysis, and QoS.
	2.5.2. Proposed Solution		2.5.2. Proposed Solution
	Including a session identifier (e.g. as defined in RFC 7206) in the		Including a session identifier (e.g. as defined in [RFC7206]) in the
	flow characteristics communicated by the application to the network		flow characteristics communicated by the application to the network
	would allow the network to identify media flows belonging to a common		would allow the network to identify media flows belonging to a common
	application session. This visibility would enable the following:		application session. This visibility would enable the following:
	o network troubleshooting and traffic analysis tools to correctly		o network troubleshooting and traffic analysis tools to correctly
	associate media flows with application sessions		associate media flows with application sessions
	o media flows that are part of established application sessions to		o media flows that are part of established application sessions to
	be identified (e.g. the triggered call in the case of a transfer)		be identified (e.g. the triggered call in the case of a transfer)
	and given dedicated QoS. Preserving established sessions		and given dedicated QoS. Preserving established sessions
	generally is higher priority than setting up new sessions (except		generally is higher priority than setting up new sessions (except
	when there is some form of multi-level preemption). Giving more		when there is some form of multi-level preemption). Giving more
	bandwidth to additional flows on established sessions might cause		bandwidth to additional flows on established sessions might cause
	some newer sessions to fail due to resource unavailability while		some newer sessions to fail due to resource unavailability while
	established sessions continue without degradation, which is the		established sessions continue without degradation, which is the
	preferred outcome in most cases.		preferred outcome in most cases.
	2.5.3. User Benefit		2.5.3. User/Application Benefit
	Users receive more predictable and reliable QoS for their application		Users receive more predictable and reliable QoS for their application
	sessions.		sessions.
	2.5.4. Operator Benefit		2.5.4. Operator Benefit
	Operators are able to perform traffic analysis and troubleshooting at		Operators are able to perform traffic analysis and troubleshooting at
	the application level, and they are able to provide QoS at the		the application level, and they are able to provide QoS at the
	application level rather than only at the media flow level.		application level rather than only at the media flow level.
	2.5.5. Application Benefit		2.5.5. Flow characteristics provided by application
	2.5.6. Flow characteristics provided by application
	The application provides a common session id as metadata for all its		The application provides a common session id as metadata for all its
	media flows throughout the lifetime of the session.		media flows throughout the lifetime of the session.
	2.5.7. Action taken by network as result of receiving flow		2.5.6. Action taken by network as result of receiving flow
	characteristics		characteristics
	The network identifies all media flows associated with a given		The network identifies all media flows associated with a given
	session. This information may be used to provide application level		session. This information may be used to provide application level
	QoS, preserving established sessions and/or giving more bandwidth to		QoS, preserving established sessions and/or giving more bandwidth to
	additional flows on established sessions.		additional flows on established sessions.
	2.5.8. Feedback provided by network		2.5.7. Feedback provided by network
	The network may provide feedback to the application indicating the		The network may provide feedback to the application indicating the
	amount of bandwidth it expects to be able to provide for its session.		amount of bandwidth it expects to be able to provide for its session.
	It may also be provide indications of the expected amount of delay,		It may also be provide indications of the expected amount of delay,
	jitter, and loss the application should be prepared to tolerate.		jitter, and loss the application should be prepared to tolerate.
	2.5.9. Security and Privacy Considerations		2.5.8. Security and Privacy Considerations
	2.6. Content Based Charging		2.6. Content Based Charging
	2.6.1. Description of Problem		2.6.1. Description of Problem
	Commonly used billing method for internet subscribers, e.g. volume		Commonly used billing method for internet subscribers, e.g. volume
	based charging, does not distinguish usage from the angle of		based charging, does not distinguish usage from the angle of
	applications. Under this billing model ISP cannot apply different		applications. Under this billing model ISP cannot apply different
	pricing strategies to the applications it carries, users may hesitate		pricing strategies to the applications it carries, users may hesitate
	to use certain types of applications, e.g. mobile apps consuming		to use certain types of applications, e.g. mobile apps consuming
	skipping to change at page 16, line 11 ¶		skipping to change at page 16, line 11 ¶
	traffic flows needing a certain charging method. Network will then		traffic flows needing a certain charging method. Network will then
	have direct visibility into the traffic and identify targeted traffic		have direct visibility into the traffic and identify targeted traffic
	accordingly. This billing model usually involves collaboration		accordingly. This billing model usually involves collaboration
	between network and content providers. The notification needs to go		between network and content providers. The notification needs to go
	through an authentication function to guarantee the application is		through an authentication function to guarantee the application is
	reliable and probably an identifier for network to identify the		reliable and probably an identifier for network to identify the
	application that has service agreement with ISP. ISP will identify		application that has service agreement with ISP. ISP will identify
	traffic based on characteristics notified by application and apply		traffic based on characteristics notified by application and apply
	designated billing strategy.		designated billing strategy.
	2.6.3. User Benefit		2.6.3. User/Application Benefit
	Users take advantage of the granular and customized charging model,		Users take advantage of the granular and customized charging model,
	and pay for different types of traffic at different rate. This		and pay for different types of traffic at different rate. This
	charging model will reduce volume expense for users and stimulate		charging model will reduce volume expense for users and stimulate
	internet usage.		internet usage. Content provider can benefit from providing users
			with exclusive payment function, e.g. pay for traffic volume or
			provide cheap volume package, and increase user enthusiasm and time
			to use its applications.
	2.6.4. Operator Benefit		2.6.4. Operator Benefit
	The solution will provide operators with a method to precisely		The solution will provide operators with a method to precisely
	identify and charge traffic based on content, and to agilely manage		identify and charge traffic based on content, and to agilely manage
	charging strategy of applications. Operators are able to cooperate		charging strategy of applications. Operators are able to cooperate
	with content providers to provide this new billing service to users		with content providers to provide this new billing service to users
	and encourage encourage traffic consumption.		and encourage encourage traffic consumption.
	2.6.5. Application Benefit		2.6.5. Flow characteristics provided by application
	Content provider can benefit from providing users with exclusive
	payment function, e.g. pay for traffic volume or provide cheap volume
	package, and increase user enthusiasm and time to use its
	applications.
	2.6.6. Flow characteristics provided by application
	Application notifies network of its identifier and traffic		Application notifies network of its identifier and traffic
	description to enable network to recognize its traffic accordingly.		description to enable network to recognize its traffic accordingly.
	Application may also signal its intended charging model as a request		Application may also signal its intended charging model as a request
	to the network.		to the network.
	2.6.7. Action taken by network as result of receiving flow		2.6.6. Action taken by network as result of receiving flow
	characteristics		characteristics
	Network identifies traffic flows notified by the application and		Network identifies traffic flows notified by the application and
	applies the designated billing model based on application request and		applies the designated billing model based on application request and
	business agreement with the content provider providing the		business agreement with the content provider providing the
	application.		application.
	2.6.8. Feedback provided by network		2.6.7. Feedback provided by network
	2.6.9. Security and Privacy Considerations		2.6.8. Security and Privacy Considerations
	There needs to be an authentication mechanism so as to ensure that		There needs to be an authentication mechanism so as to ensure that
	traffic characteristics provider is right the authorized application		traffic characteristics provider is right the authorized application
	the ISP has the charging agreement with.		the ISP has the charging agreement with.
	2.7. Open QoS and Experience Enhancement for Applications		3. Acknowledgements
	2.7.1. Description of Problem
	Current QoS provided in an ISP's network is usually circuit or user
	based, achieved by configuring policies on network nodes like edge
	router or gateway, and is not dynamic, on-demand or application
	specific. An example showing the current problem of achieving
	application granularity is the internet based home products provided
	by many content providers, e.g. an internet TV box using WiFi to
	connect the internet and providing video programs to users. Content
	providers often wish to cooperate with the ISP providing internet
	access service to improve the experience of their services, as access
	network is often congested due to extensive internet usage nowadays.
	But currently there is no direct way of classifying certain traffic
	when it is mixed with other background traffic in a single pipe, e.g.
	WiFi. Implementing classification on specific traffic of an
	individual application, e.g. text, audio, video traffic of an instant
	messaging application, is even more difficult.
	QoS provided by an ISP is usually predefined and not application
	driven. QoS ability opening provides a mechanism to enable dynamic
	access acceleration, priority guarantee and other service
	differentiation for ICPs, and new application based QoS selling
	business for network operators. By opening QoS ability to content
	providers, this mechanism is expected to allow application to
	subscribe QoS business to enhance its user experience, and manage
	traffic treatment on its own.
	2.7.2. Proposed Solution
	The potential solution proposes a collaboration mechanism for content
	provider operating the application and ISP operating the network.
	Application notifies the network of its identifier and the
	characteristics of its traffic flows needing experience enhancement.
	The notification probably conveys service request to the network,
	e.g. desired QoS, capacity guarantee, etc. The treatment traffic
	will receive is expected to be based on agreements between content
	provider and ISP, or service subscription templates provided by ISP,
	and an authentication mechanism is used by ISP to validate the party
	making the notification. Network will then know the exact
	application information of traffic, and perform traffic
	identification and differentiation on network nodes, e.g. broadband
	access router. This solution provides a way for applications to lead
	its experience enhancement.
	2.7.3. User Benefit
	Users will have enhanced experience when using the applications.
	2.7.4. Operator Benefit
	Operator is able to identify application traffic precisely and
	perform differentiated service accordingly. QoS ability of operator
	is further extended to a finer granularity and initiation and
	management of traffic differentiation is more flexible and open,
	providing operator with new business model while cooperating with
	content provider.
	2.7.5. Application Benefit
	Content provider has the ability to influence the treatment network
	give to its traffic, and decide when and how to apply QoS to its
	traffic. By enhancing experience using this mechanism user
	enthusiasm and usage time will be increased.
	2.7.6. Flow characteristics provided by application
	Application notifies network of its identifier and the
	characteristics of its traffic flows needing experience enhancement.
	Application may also notify the network of a request of desired
	traffic treatment.
	2.7.7. Action taken by network as result of receiving flow
	characteristics
	Network identifies traffic flows notified by the application and		The authors thank the attendees of the Bar BoF for contributing
	applies the designated QoS or other service guarantee based on		towards this set of use cases.
	application request and business agreement/subscription with the
	content provider providing the application.
	2.7.8. Feedback provided by network		4. Informative References
	Network may provide feedback indicating whether service request can		[I-D.conet-aeon-problem-statement]
	be satisfied or the designated service, but it is not mandatory.		Fan, P., Deng, H., Boucadair, M., Reddy, T., and C. Eckel,
			"Application Enabled Collaborative Networking: Problem
			Statement and Requirements", draft-conet-aeon-problem-
			statement-00 (work in progress), May 2014.
	2.7.9. Security and Privacy Considerations		[I-D.reddy-mmusic-ice-best-interface-pcp]
			Reddy, T., Wing, D., Steeg, B., Penno, R., and V. Varun,
			"Improving ICE Interface Selection Using Port Control
			Protocol (PCP) Flow Extension", draft-reddy-mmusic-ice-
			best-interface-pcp-00 (work in progress), October 2013.
	There needs to be an authentication mechanism so as to ensure that		[I-D.wing-mptcp-pcp]
	traffic characteristics provider is right the authorized application		Wing, D., R, R., Reddy, T., Ford, A., and R. Penno,
	cooperating with the ISP.		"Multipath TCP (MPTCP) Path Selection using PCP", draft-
			wing-mptcp-pcp-00 (work in progress), October 2013.
	3. Acknowledgements		[I-D.wing-pcp-third-party-authz]
			Wing, D., Reddy, T., Patil, P., and R. Penno, "PCP
			Extension for Third Party Authorization", draft-wing-pcp-
			third-party-authz-03 (work in progress), April 2014.
	The authors thank the attendees of the Bar BoF for contributing		[RFC7206] Jones, P., Salgueiro, G., Polk, J., Liess, L., and H.
	towards this set of use cases.		Kaplan, "Requirements for an End-to-End Session
			Identification in IP-Based Multimedia Communication
			Networks", RFC 7206, May 2014.
	Authors' Addresses		Authors' Addresses
	Wesley George		Wesley George
	Time Warner Cable		Time Warner Cable
	13820 Sunrise Valley Drive		13820 Sunrise Valley Drive
	Herndon, VA 20171		Herndon, VA 20171
	US		US
	Email: wesley.george@twcable.com		Email: wesley.george@twcable.com
	skipping to change at page 19, line 25 ¶		skipping to change at page 18, line 4 ¶
	Authors' Addresses		Authors' Addresses
	Wesley George		Wesley George
	Time Warner Cable		Time Warner Cable
	13820 Sunrise Valley Drive		13820 Sunrise Valley Drive
	Herndon, VA 20171		Herndon, VA 20171
	US		US
	Email: wesley.george@twcable.com		Email: wesley.george@twcable.com
	Peng Fan		Peng Fan
	China Mobile		China Mobile
	32 Xuanwumen West Street		32 Xuanwumen West Street
	Beijing 100053		Beijing 100053
	China		China
	Email: fanpeng@chinamobile.com		Email: fanpeng@chinamobile.com
			Satoru Matsushima
			SoftBank Telecom
			1-9-1 Higashi-Shinbashi, Munato-ku
			Tokyo
			Japan
			Email: satoru.matsushima@g.softbank.co.jp
	Tirumaleswar Reddy		Tirumaleswar Reddy
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Cessna Business Park, Varthur Hobli		Cessna Business Park, Varthur Hobli
	Sarjapur Marathalli Outer Ring Road		Sarjapur Marathalli Outer Ring Road
	Bangalore, Karnataka 560103		Bangalore, Karnataka 560103
	India		India
	Email: tireddy@cisco.com		Email: tireddy@cisco.com
	Charles Eckel		Charles Eckel
End of changes. 83 change blocks.
	257 lines changed or deleted		184 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/