draft-fairhurst-tsvwg-transport-encrypt-06.txt		draft-fairhurst-tsvwg-transport-encrypt-07.txt
	TSVWG G. Fairhurst		TSVWG G. Fairhurst
	Internet-Draft University of Aberdeen		Internet-Draft University of Aberdeen
	Intended status: Informational C.S. Perkins		Intended status: Informational C.S. Perkins
	Expires: August 11, 2018 University of Glasgow		Expires: October 10, 2018 University of Glasgow
	February 9, 2018		April 10, 2018
	The Impact of Transport Header Confidentiality on Network Operation and		The Impact of Transport Header Confidentiality on Network Operation and
	Evolution of the Internet		Evolution of the Internet
	draft-fairhurst-tsvwg-transport-encrypt-06		draft-fairhurst-tsvwg-transport-encrypt-07
	Abstract		Abstract
	This document describes implications of applying end-to-end		This document describes implications of applying end-to-end
	encryption at the transport layer. It identifies in-network uses of		encryption at the transport layer. It identifies in-network uses of
	transport layer header information. It then reviews the implications		transport layer header information. It then reviews the implications
	of developing end-to-end transport protocols that use encryption to		of developing end-to-end transport protocols that use encryption to
	provide confidentiality of the transport protocol header and expected		provide confidentiality of the transport protocol header and expected
	implications of transport protocol design and network operation.		implications of transport protocol design and network operation.
	Since transport measurement and analysis of the impact of network		Since transport measurement and analysis of the impact of network
	skipping to change at page 1, line 41 ¶		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 August 11, 2018.		This Internet-Draft will expire on October 10, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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 (http://trustee.ietf.org/		Provisions Relating to IETF Documents (http://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Current uses of Transport Headers within the Network . . . . . 8		2. Current uses of Transport Headers within the Network . . . . . 8
	2.1. Observing Transport Information in the Network . . . . . . 8		2.1. Observing Transport Information in the Network . . . . . . 9
	2.1.1. Flow Identification . . . . . . . . . . . . . . . . . 9		2.1.1. Flow Identification . . . . . . . . . . . . . . . . . 9
	2.1.2. Metrics derived from Transport Layer Headers . . . . . 9		2.1.2. Metrics derived from Transport Layer Headers . . . . . 10
	2.1.3. Metrics derived from Network Layer Headers . . . . . . 12		2.1.3. Metrics derived from Network Layer Headers . . . . . . 12
	2.2. Transport Measurement . . . . . . . . . . . . . . . . . . 14		2.2. Transport Measurement . . . . . . . . . . . . . . . . . . 14
	2.2.1. Point of Measurement . . . . . . . . . . . . . . . . . 14		2.2.1. Point of Measurement . . . . . . . . . . . . . . . . . 14
	2.2.2. Use by Operators to Plan and Provision Networks . . . 15		2.2.2. Use by Operators to Plan and Provision Networks . . . 15
	2.2.3. Service Performance Measurement . . . . . . . . . . . 15		2.2.3. Service Performance Measurement . . . . . . . . . . . 15
	2.2.4. Measuring Transport to Support Network Operations . . 16		2.2.4. Measuring Transport to Support Network Operations . . 16
	2.3. Use for Network Diagnostics and Troubleshooting . . . . . 17		2.3. Use for Network Diagnostics and Troubleshooting . . . . . 17
	2.3.1. Examples of measurements . . . . . . . . . . . . . . . 17		2.3.1. Examples of measurements . . . . . . . . . . . . . . . 18
	2.4. Observing Headers to Implement Network Policy . . . . . . 18		2.4. Observing Headers to Implement Network Policy . . . . . . 19
	3. Encryption and Authentication of Transport Headers . . . . . . 18		3. Encryption and Authentication of Transport Headers . . . . . . 19
	3.1. Authenticating the Transport Protocol Header . . . . . . . 20		3.1. Authenticating the Transport Protocol Header . . . . . . . 21
	3.2. Encrypting the Transport Payload . . . . . . . . . . . . . 20		3.2. Encrypting the Transport Payload . . . . . . . . . . . . . 21
	3.3. Encrypting the Transport Header . . . . . . . . . . . . . 20		3.3. Encrypting the Transport Header . . . . . . . . . . . . . 21
	3.4. Authenticating Transport Information and Selectively		3.4. Authenticating Transport Information and Selectively
	Encrypting the Transport Header . . . . . . . . . . . . . 21		Encrypting the Transport Header . . . . . . . . . . . . . 22
	3.5. Optional Encryption of Header Information . . . . . . . . 21		3.5. Optional Encryption of Header Information . . . . . . . . 22
	4. Addition of Transport Information to Network-Layer Protocol		4. Addition of Transport Information to Network-Layer Protocol
	Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 21		Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	5. Implications of Protecting the Transport Headers . . . . . . . 22		5. Implications of Protecting the Transport Headers . . . . . . . 23
	5.1. Independent Measurement . . . . . . . . . . . . . . . . . 22		5.1. Independent Measurement . . . . . . . . . . . . . . . . . 23
	5.2. Characterising "Unknown" Network Traffic . . . . . . . . . 23		5.2. Characterising "Unknown" Network Traffic . . . . . . . . . 24
	5.3. Accountability and Internet Transport Protocols . . . . . 23		5.3. Accountability and Internet Transport Protocols . . . . . 24
	5.4. Impact on Research, Development and Deployment . . . . . . 24		5.4. Impact on Research, Development and Deployment . . . . . . 25
	6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 25		6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 27		8. Security Considerations . . . . . . . . . . . . . . . . . . . 29
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	10.1. Normative References . . . . . . . . . . . . . . . . . . 28		10.1. Normative References . . . . . . . . . . . . . . . . . . 29
	10.2. Informative References . . . . . . . . . . . . . . . . . 28		10.2. Informative References . . . . . . . . . . . . . . . . . 29
	Appendix A. Revision information . . . . . . . . . . . . . . . . . 32		Appendix A. Revision information . . . . . . . . . . . . . . . . . 34
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
	1. Introduction		1. Introduction
	This document describes implications of applying end-to-end		This document describes implications of applying end-to-end
	encryption at the transport layer. It reviews the implications of		encryption at the transport layer. It reviews the implications of
	developing end-to-end transport protocols that use encryption to		developing end-to-end transport protocols that use encryption to
	provide confidentiality of the transport protocol header and expected		provide confidentiality of the transport protocol header and expected
	implications of transport protocol design and network operation. It		implications of transport protocol design and network operation. It
	also considers anticipated implications on transport and application		also considers anticipated implications on transport and application
	evolution.		evolution.
	The transport layer provides the first end-to-end interactions across		The transport layer provides the first end-to-end interactions across
	the Internet. Transport protocols layer directly over the network-		the Internet. Transport protocols layer directly over the network-
	layer service and are sent in the payload of network-layer packets.		layer service and are sent in the payload of network-layer packets.
	They support end-to-end communication between applications, supported		They support end-to-end communication between applications, supported
	by higher-layer protocols, running on the end systems (or transport		by higher-layer protocols, running on the end systems (or transport
	endpoints). This simple architectural view hides one of the core		endpoints). This simple architectural view hides one of the core
	functions of the transport, however - to discover and adapt to the		functions of the transport, however, to discover and adapt to the
	properties of the Internet path that is currently being used. The		properties of the Internet path that is currently being used. The
	design of Internet transport protocols is as much about trying to		design of Internet transport protocols is as much about trying to
	avoid the unwanted side effects of congestion on a flow and other		avoid the unwanted side effects of congestion on a flow and other
	capacity-sharing flows, avoiding congestion collapse, adapting to		capacity-sharing flows, avoiding congestion collapse, adapting to
	changes in the path characteristics, etc., as it is about end-to-end		changes in the path characteristics, etc., as it is about end-to-end
	feature negotiation, flow control and optimising for performance of a		feature negotiation, flow control and optimising for performance of a
	specific application.		specific application.
	To achieve stable Internet operations the IETF transport community		To achieve stable Internet operations the IETF transport community
	has to date relied heavily on measurement and insights of the network		has to date relied heavily on measurement and insights of the network
	operations community to understand the trade-offs, and to inform		operations community to understand the trade-offs, and to inform
	selection of appropriate mechanisms, to ensure a safe, reliable, and		selection of appropriate mechanisms, to ensure a safe, reliable, and
	robust Internet (e.g., [RFC1273]). In turn, the network operations		robust Internet (e.g., [RFC1273]). In turn, the network operations
	community relies on being able to understand the pattern and		community relies on being able to understand the pattern and
	requirements of traffic passing over the Internet, both in aggregate		requirements of traffic passing over the Internet, both in aggregate
	and at the flow level - inspecting transport layer headers to help		and at the flow level.
	understand traffic dynamics.
	There are many motivations for deploying encrypted transports (i.e.,		There are many motivations for deploying encrypted transports (i.e.,
	transport protocols that use encryption to provide confidentiality of		transport protocols that use encryption to provide confidentiality of
	some or all of the transport-layer header information), and		some or all of the transport-layer header information), and
	encryption of transport payloads (i.e. Confidentiality of the		encryption of transport payloads (i.e. confidentiality of the
	payload data). The increasing public concerns about the interference		payload data). The increasing public concerns about the interference
	with Internet traffic have led to a rapidly expanding deployment of		with Internet traffic have led to a rapidly expanding deployment of
	encryption to protect end-user privacy, in protocols like QUIC, but		encryption to protect end-user privacy, in protocols like QUIC [I-D
	also expected to forma a basis of future protocol designs.		.ietf-quic-transport], but also expected to form a basis of future
			protocol designs.
	Introducing cryptographic integrity checks to header fields can also
	prevent undetected manipulation of the field by network devices.
	However, it does not prevent inspection of the information by device
	on path, and it is possible that such devices could develop
	mechanisms that rely on the presence of such a field, or a known
	value in the field. This leads to ossification of the header: An
	endpoint could be required to supply the header to receive the
	network service that it desires. In some cases, this could be benign
	to the protocol (e.g., recognising the start of a connection), but in
	other cases, any change to the protocol use of a specific header can
	have undesirable implications (e.g., a mechanism implemented in a
	network device, such as a firewall, that requires a header field to
	have only a specific known set of values could prevent the device
	from forwarding packets using a different version of a protocol that
	introduces a new feature that changes the value present in this
	field). A protocol that intentionally varies the format and value of
	header fields (sometimes known as Greasing) has been suggested as a
	way to help avoid such ossification of the transport protocol.
	Implementations of network devices are encouraged to avoid side-		Implementations of network devices are encouraged to avoid side-
	effects when protocols are updated. In particular, it is important		effects when protocols are updated. Introducing cryptographic
	that protocols either do not expose information where the usage may		integrity checks to header fields can also prevent undetected
	change in future protocols, or that methods that utilise the		manipulation of the field by network devices, or undetected addition
	information are robust to potential changes as protocols evolve over		of information to a packet. However, this does not prevent
	time.		inspection of the information by a device on path, and it is possible
			that such devices could develop mechanisms that rely on the presence
	At the same time, some network operators and access providers, have		of such a field, or a known value in the field. Reliance on the
	come to rely on the in-network measurement of transport properties		presence and semantics of packet headers leads to ossification: An
	and the functionality provided by middleboxes to both support network		endpoint could be required to supply a specific header to receive the
	operations and enhance performance (e.g., [I-D.dolson-plus-middlebox-		network service that it desires. In some cases, this could be benign
	benefits]).		to the protocol (e.g., recognising the start of a connection), but
			not in all cases (e.g., a mechanism implemented in a network device,
			such as a firewall, could require a header field to have only a
			specific known set of values could prevent the device from forwarding
			packets using a different version of a protocol that introduces a new
			feature that changes the value present in this field).
	A protocol design can use header encryption to provide		A protocol design can use header encryption to provide
	confidentiality of some or all of the protocol header information.		confidentiality of some or all of the protocol header information.
	This prevents an on-path device from knowledge of the header field.		This prevents an on-path device from knowledge of the header field.
	It therefore prevents mechanisms being built that directly rely on		It therefore prevents mechanisms being built that directly rely on
	the information or seeks to imply semantics of an exposed header		the information or seeks to imply semantics of an exposed header
	field. Protocol designers have often ignored these implications and		field. Using encryption to provide confidentiality of the transport
	this document suggests that exposure of information should be		layer brings some well-known privacy and security benefits and can
	carefully considered when specifying new protocols.		therefore help reduce ossification of the transport layer. In
			particular, it is important that protocols either do not expose
			information where the usage may change in future protocols, or that
			methods that utilise the information are robust to potential changes
			as protocols evolve over time. To avoid unwanted inspection, a
			protocol could also intentionally vary the format and value of header
			fields (sometimes known as Greasing [I-D.thomson-quic-grease]).
	Using encryption to provide confidentiality of the transport layer		At the same time, some network operators and access providers, have
	brings some well-known privacy and security benefits. While a		come to rely on the in-network measurement of transport properties
	protocol design that encrypts (hides) all the transport information		and the functionality provided by middleboxes to both support network
	can help reduce ossification of the transport layer, it could result		operations and enhance performance. There can therefore be
	in ossification of the network service. There can be advantages in		implications when working with encrypted transport protocols that
	providing a level of ossification of the header in terms of providing		hide transport header information from the network. This present
	a set of specified header fields that are observable from in-network		architectural challenges and considerations in the way transport
	devices.		protocols are designed, and ability to characterise and compare
			different transport solutions [Measure].
	There can also be implications when working with encrypted transport		A level of ossification of the header can be advantageous in terms of
	protocols that hide transport header information from the network.		providing a set of specified header fields that become observable by
	This present architectural challenges and considerations in the way		in-network devices. This results in trade-offs around
	transport protocols are designed, and ability to characterise and		authentication, and confidentiality of transport protocol headers and
	compare different transport solutions [Measure]. This results in		the potential support for other uses of this header information. For
	trade-offs around authentication, and confidentiality of transport		example, a design that provides confidentiality of protocol header
	protocol headers and the potential support for other uses of this		information can impact the following activities that rely on
	header information. For example, it can impact the following		measurement and analysis of traffic flows:
	activities that rely on measurement and analysis of traffic flows:
	Network Operations and Research: Observable transport headers enable		Network Operations and Research: Observable transport headers enable
	both operators and the research community to measure and analyse		both operators and the research community to measure and analyse
	protocol performance, network anomalies, and failure pathologies.		protocol performance, network anomalies, and failure pathologies.
	This information can help inform capacity planning, and assist in		This information can help inform capacity planning, and assist in
	determining the need for equipment and/or configuration changes by		determining the need for equipment and/or configuration changes by
	network operators.		network operators.
	This data information can inform Internet engineering research,		The data can also inform Internet engineering research, and help
	and help the development of new protocols, methodologies, and		the development of new protocols, methodologies, and procedures.
	procedures. Hiding the entire transport protocol, including		Concealing the transport protocol header information makes the
	header information, will restrict the availability of data, and		stream performance unavailable to passive observers along the
	might lead to the development of alternative, and potentially more		path, and likely leads to the development of alternative methods
	intrusive, methods to acquire the needed data.		to collect or infer that data.
	Providing confidentiality of the transport payload, but leaving		Providing confidentiality of the transport payload, but leaving
	some, or all, of the transport headers unencrypted, possibly with		some, or all, of the transport headers unencrypted, possibly with
	authentication, can provide the majority of the privacy and		authentication, can provide the majority of the privacy and
	security benefits while allowing some measurement.		security benefits while allowing some measurement.
	Protection from Denial of Service: Observable transport headers can		Protection from Denial of Service: Observable transport headers
	provide useful input to classification of traffic and detection of		currently provide useful input to classify traffic and detect
	anomalous events, such as distributed denial of service attacks.		anomalous events (e.g., changes in application behaviour,
	To be effective, this protection needs to be able to uniquely		distributed denial of service attacks). To be effective, this
	disambiguate unwanted traffic. An inability to separate this		protection needs to be able to uniquely disambiguate unwanted
	traffic using packet header information is expected to lead to		traffic. An inability to separate this traffic using packet
	less precise pattern matching techniques or resort to		header information may result in less-efficient identification of
	indiscriminately (rate) limiting uncharacterised traffic.		unwanted traffic or development of different methods (e.g. rate-
			limiting of uncharacterised traffic).
	Network Troubleshooting and Diagnostics: Encrypting transport header		Network Troubleshooting and Diagnostics: Encrypting transport header
	information eliminates the incentive for operators to troubleshoot		information eliminates the incentive for operators to troubleshoot
	what they cannot interpret. A flow experiencing packet loss looks		what they cannot interpret. A flow experiencing packet loss or
	like an unaffected flow when only observing network layer headers		jitter looks like an unaffected flow when only observing network
	(if transport sequence numbers and flow identifiers are obscured).		layer headers (if transport sequence numbers and flow identifiers
	This limits understanding of the impact of packet loss on the		are obscured). This limits understanding of the impact of packet
	flows that share a network segment. Encrypted traffic therefore		loss or latency on the flows, or even localizing the network
	implies "don't touch", and a likely trouble-shooting response will		segment causing the packet loss or latency. Encrypted traffic may
	be "can't help, no trouble found". The additional mechanisms that		imply "don't touch" to some, and could limit a trouble-shooting
	will need to be introduced to help reconstruct transport-level		response to "can't help, no trouble found". The additional
	metrics add complexity and operational costs [I-D.mm-wg-effect-		mechanisms that will need to be introduced to help reconstruct
	encrypt].		transport-level metrics add complexity and operational costs
			(e.g., in deploying additional functions in equipment or adding
			traffic overhead).
	Network Traffic Analysis: Hiding transport protocol header		Network Traffic Analysis: Hiding transport protocol header
	information can make it harder to determine which transport		information can make it harder to determine which transport
	protocols and features are being used across a network segment.		protocols and features are being used across a network segment and
	The trends in usage. This could impact the ability for an		to measure trends in the pattern of usage. This could impact the
	operator to anticipate the need for network upgrades and roll-out.		ability for an operator to anticipate the need for network
	It can also impact the on-going traffic engineering activities		upgrades and roll-out. It can also impact the on-going traffic
	performed by operators. While the impact may, in many cases, be		engineering activities performed by operators (such as determining
	small there are scenarios where operators directly support		which parts of the path contribute delay, jitter or loss). While
	particular services (e.g., in radio links, or to troubleshoot		the impact may, in many cases, be small there are scenarios where
	issues relating to Quality of Service, QoS; the ability to perform		operators directly support particular services (e.g., to
	fast re-routing of critical traffic, or support to mitigate the		troubleshoot issues relating to Quality of Service, QoS; the
	characteristics of specific radio links). The more complex the		ability to perform fast re-routing of critical traffic, or support
	underlying infrastructure the more important this impact.		to mitigate the characteristics of specific radio links). The more
			complex the underlying infrastructure the more important this
			impact.
	Open and Verifiable Network Data: The Hiding transport protocol		Open and Verifiable Network Data: Hiding transport protocol header
	header information can reduces the range of actors that can		information can reduce the range of actors that can capture useful
	capture useful measurement data. This is, of course, its goal.		measurement data. For example, one approach could be to employ an
	Doing so, however, limits the information sources available to the		existing transport protocol that reveals little information (e.g.,
	Internet community to understand the operation of transport		UDP), and perform traditional transport functions at higher layers
	protocols, so preventing access to the information necessary to		protecting the confidentiality of transport information. Such a
	inform design decisions and standards for new protocols and		design, limits the information sources available to the Internet
	related operational practices.		community to understand the operation of new transport protocols,
			so preventing access to the information necessary to inform design
			decisions and standardisation of the new protocols and related
			operational practices.
	There are dangers in a model where only endpoints (i.e., at user		The cooperating dependence of network, application, and host to
	devices and within service platforms) can observe performance, and		provide communication performance on the Internet is uncertain
	this cannot be independently verified.		when only endpoints (i.e., at user devices and within service
			platforms) can observe performance, and performance cannot be
			independently verified by all parties. The ability of other
			stakeholders to review code can help develop deeper insight. In
			the heterogeneous Internet, this helps extend the range of
			topologies, vendor equipment, and traffic patterns that are
			evaluated.
	To ensure the health of the standards and research communities, we		Independently captured data is important to help ensure the health
	need independently captured data to develop new transport protocol		of the research and development communities. It can provide input
	mechanisms based on the behaviour experienced in deployed		and test scenarios to support development of new transport
	networks.		protocol mechanisms, especially when this analysis can be based on
			the behaviour experienced in a diversity of deployed networks.
	Independently verifiable performance metrics might also important		Independently verifiable performance metrics might also be
	in order to demonstrate regulatory compliance in some		important to demonstrate regulatory compliance in some
	jurisdictions.		jurisdictions, and provides an important basis for informing
			design decisions.
	The last point leads us to consider the impact of hiding transport		The last point leads us to consider the impact of hiding transport
	headers in the specification and development of protocols and		headers in the specification and development of protocols and
	standards. This has potential impact on:		standards. This has potential impact on:
	o Understanding Feature Interactions: An appropriate vantage point,		o Understanding Feature Interactions: An appropriate vantage point,
	coupled with timing information about traffic flows, provides a		coupled with timing information about traffic flows, provides a
	valuable tool for benchmarking equipment, functions, and/or		valuable tool for benchmarking equipment, functions, and/or
	configurations, and to understand complex feature interactions.		configurations, and to understand complex feature interactions.
	An inability to observe transport protocol information can limit		An inability to observe transport protocol information can limit
	the ability to diagnose and explore interactions between features		the ability to diagnose and explore interactions between features
	at different protocol layers, a side-effect of not allowing a		at different protocol layers, a side-effect of not allowing a
	choice of vantage point from which this information is observed.		choice of vantage point from which this information is observed.
	o Supporting Common Specifications: The Transmission Control		o Supporting Common Specifications: The Transmission Control
	Protocol (TCP) is the predominant transport protocol used over		Protocol (TCP) is currently the predominant transport protocol
	Internet paths. Its many variants have broadly consistent		used over Internet paths. Its many variants have broadly
	approaches to avoiding congestion collapse, and to ensuring the		consistent approaches to avoiding congestion collapse, and to
	stability of the network. Increased use of transport layer		ensuring the stability of the Internet. Increased use of
	encryption can overcome ossification, allowing deployment of new		transport layer encryption can overcome ossification, allowing
	transports and different types of congestion control. This		deployment of new transports and different types of congestion
	flexibility can be beneficial, but it can come at the cost of		control. This flexibility can be beneficial, but it can come at
	fragmenting the ecosystem. There is little doubt that developers		the cost of fragmenting the ecosystem. There is little doubt that
	will try to produce high quality transports for their target uses,		developers will try to produce high quality transports for their
	but it is not clear there are sufficient incentives to ensure good		intended target uses, but it is not clear there are sufficient
	practice that benefits the wide diversity of requirements for the		incentives to ensure good practice that benefits the wide
	Internet community as a whole. Increased diversity, and the		diversity of requirements for the Internet community as a whole.
	ability to innovate without public scrutiny, risks point solutions		Increased diversity, and the ability to innovate without public
	that optimise for specific needs, but accidentally disrupt		scrutiny, risks point solutions that optimise for specific needs,
	operations of/in different parts of the network. The social		but accidentally disrupt operations of/in different parts of the
	contract that maintains the stability of the network relies on		network. The social contract that maintains the stability of the
	accepting common specifications, and on the ability to verify that		Internet relies on accepting common specifications, and on the
	others also conform.		ability to verify that others also conform.
	o Operational practice: Published transport specifications allow		o Operational practice: Published transport specifications allow
	operators to check compliance. This can bring assurance to those		operators to check compliance. This can bring assurance to those
	operating networks, often avoiding the need to deploy complex		operating networks, often avoiding the need to deploy complex
	techniques that routinely monitor and manage TCP/IP traffic flows		techniques that routinely monitor and manage TCP/IP traffic flows
	(e.g. Avoiding the capital and operational costs of deploying		(e.g. Avoiding the capital and operational costs of deploying
	flow rate-limiting and network circuit-breaker methods [RFC8084]).		flow rate-limiting and network circuit-breaker methods [RFC8084]).
	When it is not possible to observe transport header information,		When it is not possible to observe transport header information,
	methods are still needed to confirm that the traffic produced		methods are still needed to confirm that the traffic produced
	conforms to the expectations of the operator or developer.		conforms to the expectations of the operator or developer.
	o Restricting research and development: Hiding transport information		o Restricting research and development: Hiding transport information
	can impede independent research into new mechanisms, measurement		can impede independent research into new mechanisms, measurement
	of behaviour, and development initiatives. Experience shows that		of behaviour, and development initiatives. Experience shows that
	transport protocols are complicated to design and complex to		transport protocols are complicated to design and complex to
	deploy, and that individual mechanisms need to be evaluated while		deploy, and that individual mechanisms need to be evaluated while
	considering other mechanisms, across a broad range of network		considering other mechanisms, across a broad range of network
	topologies and with attention to the impact on traffic sharing the		topologies and with attention to the impact on traffic sharing the
	capacity. Hiding transport header information (e.g., by pervasive		capacity. If this results in reduced availability of open data,
	encryption of transport information) could eliminate the		it could eliminate the independent self-checks to the
	independent self-checks that have previously been in place from		standardisation process that have previously been in place from
	research and academic contributors (e.g., the role of the IRTF		research and academic contributors (e.g., the role of the IRTF
	ICCRG, and research publications in reviewing new transport		ICCRG, and research publications in reviewing new transport
	mechanisms and assessing the impact of their experimental		mechanisms and assessing the impact of their experimental
	deployment).		deployment)
	In summary, a lack of visibility of transport header information can		In summary, there are tradeoffs. On the one hand, protocol designers
	impact the ways that protocols are designed, standardised, deployed,		have often ignored the implications of whether the information in
	and operated. The choice of whether future transport protocols		transport header fields can or will be used by in-network devices,
	encrypt their protocol headers therefore needs to be taken based not		and the implications this places on protocol evolution. This
	solely on security and privacy considerations, but also taking into		motivates a design that provides confidentiality of the header
	account the impact on operations, standards, and research. A network		information. On the other hand, it can be expected that a lack of
	that is secure but unusable due to persistent congestion collapse is		visibility of transport header information can impact the ways that
	not an improvement, and while that would be an extreme outcome		protocols are deployed, standardised, and their operational support.
	proposals that impose high costs for very limited benefits need to be		The choice of whether future transport protocols encrypt their
	considered carefully, to ensure the benefits outweigh the costs.		protocol headers therefore needs to be taken based not solely on
			security and privacy considerations, but also taking into account the
			impact on operations, standards, and research. Any new Internet
			transport need to provide appropriate transport mechanisms and
			operational support to assure the resulting traffic can not result in
			persistent congestion collapse [RFC2914]. This document suggests
			that the balance between information exposed and concealed should be
			carefully considered when specifying new protocols.
	2. Current uses of Transport Headers within the Network		2. Current uses of Transport Headers within the Network
	Despite transport headers having end-to-end meaning, some of these		Despite transport headers having end-to-end meaning, some of these
	transport headers have come to be used in various ways within the		transport headers have come to be used in various ways within the
	Internet. In response to pervasive monitoring [RFC7624] revelations		Internet. In response to pervasive monitoring [RFC7624] revelations
	and the IETF consensus that "Pervasive Monitoring is an Attack"		and the IETF consensus that "Pervasive Monitoring is an Attack"
	[RFC7258], efforts are underway to increase encryption of Internet		[RFC7258], efforts are underway to increase encryption of Internet
	traffic,. Applying confidentiality to transport header fields would		traffic,. Applying confidentiality to transport header fields would
	affect how network protocols are designed and used [I-D.mm-wg-effect-		affect how protocol information is used [I-D.mm-wg-effect-encrypt].
	encrypt]. To understand these implications, it is first necessary to		To understand these implications, it is first necessary to understand
	understand how transport layer headers are currently observed and/or		how transport layer headers are currently observed and/or modified by
	modified by middleboxes within the network.		middleboxes within the network.
	Transport protocols can be designed to encrypt or authenticate		Transport protocols can be designed to encrypt or authenticate
	transport header fields. Authentication methods at the transport		transport header fields. Authentication at the transport layer can
	layer can be used to detect any changes to an immutable header field		be used to detect any changes to an immutable header field that were
	that were made by a network device along a path. The intentional		made by a network device along a path. The intentional modification
	modification of transport headers by middleboxes (such as Network		of transport headers by middleboxes (such as Network Address
	Address Translation, NAT, or Firewalls) is not considered. Common		Translation, NAT, or Firewalls) is not considered. Common issues
	issues concerning IP address sharing are described in [RFC6269].		concerning IP address sharing are described in [RFC6269].
	2.1. Observing Transport Information in the Network		2.1. Observing Transport Information in the Network
	In-network observation of transport protocol headers requires		In-network observation of transport protocol headers requires
	knowledge of the format of the transport header:		knowledge of the format of the transport header:
	o Flows need to be identified at the level required for monitoring;		o Flows need to be identified at the level required for monitoring;
	o The protocol and version of the header need to be observable. As		o The protocol and version of the header need to be observable. As
	protocols evolve over time and there may be a need to introduce		protocols evolve over time and there may be a need to introduce
	new transport headers. This may require interpretation of		new transport headers. This may require interpretation of
	protocol version information or connection setup information;		protocol version information or connection setup information;
	o Location and syntax of any transport headers to be observed. IETF		o Location and syntax of any transport headers needs to be known to
	transport protocols specify this information.		be observed. IETF transport protocols specify this information.
	The following subsections describe various ways that observable		The following subsections describe various ways that observable
	transport information may be utilised.		transport information may be utilised.
	2.1.1. Flow Identification		2.1.1. Flow Identification
	Transport protocol header information (with information in the		Transport protocol header information (together with information in
	network header), can identify a flow and the connection state of the		the network header), can identify a flow and the connection state of
	flow, together with the protocol options being used. In some usages,		the flow, together with the protocol options being used. In some
	a low-numbered (well-known ) port number can identify a protocol		usages, a low-numbered (well-known) transport port number can
	(although port information alone is not sufficient to guarantee		identify a protocol (although port information alone is not
	identification of a protocol). Transport protocols, such as TCP and		sufficient to guarantee identification of a protocol). Transport
	Stream Control Transport Protocol (SCTP) specify a standard base		protocols, such as TCP and Stream Control Transport Protocol (SCTP)
	header that includes sequence number information and other data, with		specify a standard base header that includes sequence number
	the possibility to negotiate additional headers at connection setup,		information and other data, with the possibility to negotiate
	identified by an option number in the transport header. UDP-based		additional headers at connection setup, identified by an option
	protocols can use, but sometimes do not use, well-known port numbers.		number in the transport header. UDP-based protocols can use, but
	Some can instead be identified by signalling protocols or through the		sometimes do not use, well-known port numbers. Some can instead be
	use of magic numbers placed in the first byte(s) of the datagram		identified by signalling protocols or through the use of magic
	payload.		numbers placed in the first byte(s) of the datagram payload.
	Flow identification is more complex and less easily achieved when		Flow identification is more complex and less easily achieved when
	multiplexing is used at or above the transport layer.		multiplexing is used at or above the transport layer.
	2.1.2. Metrics derived from Transport Layer Headers		2.1.2. Metrics derived from Transport Layer Headers
	Some actors have a need to characterise the performance of link/		Some actors manage their portion of the Internet by characterizing
	network segments. Passive monitoring uses observed traffic to makes		the performance of link/network segments. Passive monitoring uses
	inferences from transport headers to derive these measurements. A		observed traffic to makes inferences from transport headers to derive
	variety of open source and commercial tools have been deployed that		these measurements. A variety of open source and commercial tools
	utilise this information. The following metrics can be derived from		have been deployed that utilise this information. The following
	transport header information:		metrics can be derived from transport header information:
	Traffic Rate and Volume: Header information e.g., (sequence number,		Traffic Rate and Volume: Header information e.g., (sequence number,
	length) may allow derivation of volume measures per-application,		length) may allow derivation of volume measures per-application,
	to characterise the traffic that uses a network segment or the		to characterise the traffic that uses a network segment or the
	pattern of network usage. This may be measured per endpoint or		pattern of network usage. This may be measured per endpoint or
	for an aggregate of endpoints (e.g., by an operator to assess		for an aggregate of endpoints (e.g., by an operator to assess
	subscriber usage). It can also be used to trigger measurement-		subscriber usage). It can also be used to trigger measurement-
	based traffic shaping and to implement QoS support within the		based traffic shaping and to implement QoS support within the
	network and lower layers. Volume measures can be valuable for		network and lower layers. Volume measures can be valuable for
	capacity planning (providing detail of trends rather than the		capacity planning (providing detail of trends rather than the
	volume per subscriber).		volume per subscriber).
	Loss Rate and Loss Pattern: Flow loss rate may be derived (e.g., from		Loss Rate and Loss Pattern: Flow loss rate may be derived (e.g., from
	sequence number) and is often used as a metric for performance		sequence number) and is often used as a metric for performance
	assessment and to characterise transport behaviour. Understanding		assessment and to characterise transport behaviour. Understanding
	the root cause of loss can help an operator determine whether this		the root cause of loss can help an operator determine whether this
	requires corrective action. Network operators may also use the		requires corrective action. Network operators may also use the
	variation in patterns of loss as a key performance metric,		variation in patterns of loss as a key performance metric,
	utilising this to detect changes in the offered service.		utilising this to detect changes in the offered service.
	There are various cause of loss, including: corruption on a link		There are various causes of loss, including: corruption of link
	(e.g., interference on a radio link), buffer overflow (e.g., due		frames (e.g., interference on a radio link), buffer overflow
	to congestion), policing (traffic management), buffer management		(e.g., due to congestion), policing (traffic management), buffer
	(e.g., Active Queue Management, AQM), inadequate provision of		management (e.g., Active Queue Management, AQM), inadequate
	traffic preemption. Understanding flow loss rate requires either		provision of traffic preemption. Understanding flow loss rate
	maintaining per flow packet counters or by observing sequence		requires either maintaining per flow packet counters or by
	numbers in transport headers. Loss can be monitored at the		observing sequence numbers in transport headers. Loss can be
	interface level by devices in the network. It is often important		monitored at the interface level by devices in the network. It is
	to understand the conditions under which packet loss occurs. This		often important to understand the conditions under which packet
	usually requires relating loss to the traffic flowing on the		loss occurs. This usually requires relating loss to the traffic
	network node/segment at the time of loss.		flowing on the network node/segment at the time of loss.
	Observation of transport feedback information (observing loss		Observation of transport feedback information (observing loss
	reports, e.g., RTP Control Protocol (RTCP), TCP SACK) can increase		reports, e.g., RTP Control Protocol (RTCP), TCP SACK) can increase
	understanding of the impact of loss and help identify cases where		understanding of the impact of loss and help identify cases where
	loss may have been wrongly identified, or the transport did not		loss may have been wrongly identified, or the transport did not
	require the lost packet. It is sometimes more important to		require the lost packet. It is sometimes more important to
	understand the pattern of loss, than the loss rate - since losses		understand the pattern of loss, than the loss rate, because losses
	can often occur as bursts, rather than randomly-timed events.		can often occur as bursts, rather than randomly-timed events.
	Throughput and Goodput: The throughput observed by a flow can be		Throughput and Goodput: The throughput achieved by a flow can be
	determined even when a flow is encrypted, providing the individual		determined even when a flow is encrypted, providing the individual
	flow can be identified. Goodput [RFC7928] is a measure of useful		flow can be identified. Goodput [RFC7928] is a measure of useful
	data exchanged (the ratio of useful/total volume of traffic sent		data exchanged (the ratio of useful/total volume of traffic sent
	by a flow), which requires ability to differentiate loss and		by a flow). This requires ability to differentiate loss and
	retransmission of packets (e.g., by observing packet sequence		retransmission of packets (e.g., by observing packet sequence
	numbers in the TCP or the Real Time Protocol, RTP, headers		numbers in the TCP or the Real Time Protocol, RTP, headers
	[RFC3550]).		[RFC3550]).
	Latency: Latency is a key performance metric that impacts application		Latency: Latency is a key performance metric that impacts application
	response time and user-perceived response time. It often		response time and user-perceived response time. It often
	indirectly impacts throughput and flow completion time. Latency		indirectly impacts throughput and flow completion time. Latency
	determines the reaction time of the transport protocol itself,		determines the reaction time of the transport protocol itself,
	impacting flow setup, congestion control, loss recovery, and other		impacting flow setup, congestion control, loss recovery, and other
	transport mechanisms. The observed latency can have many		transport mechanisms. The observed latency can have many
	components [Latency]. Of these, unnecessary/unwanted queuing in		components [Latency]. Of these, unnecessary/unwanted queuing in
	network buffers has often been observed as a significant factor.		network buffers has often been observed as a significant factor.
	Once the cause of unwanted latency has been identified, this can		Once the cause of unwanted latency has been identified, this can
	often be eliminated, and determining latency metrics is a key		often be eliminated.
	driver in the deployment of AQM [RFC7567], DiffServ [RFC2474], and
	Explicit Congestion Notification (ECN) [RFC3168] [RFC8087].
	To measure latency across a part of a path, an observation point		To measure latency across a part of a path, an observation point
	can measure the experienced round trip time (RTT) using packet		can measure the experienced round trip time (RTT) using packet
	sequence numbers, and acknowledgements, or by observing header		sequence numbers, and acknowledgements, or by observing header
	timestamp information. Such information allows an observation		timestamp information. Such information allows an observation
	point in the network to determine not only the path RTT, but also		point in the network to determine not only the path RTT, but also
	to measure the upstream and downstream contribution to the RTT.		to measure the upstream and downstream contribution to the RTT.
	This may be used to locate a source of latency, e.g., by observing		This can be used to locate a source of latency, e.g., by observing
	cases where the ratio of median to minimum RTT is large for a part		cases where the ratio of median to minimum RTT is large for a part
	of a path.		of a path.
	An example usage of this method could identify excessive buffers		The service offered by operators can benefit from latency
	to help deploy or configure AQM [RFC7567] [RFC7928] to effectively
	eliminate unnecessary queuing in routers and other devices. AQM
	methods need to be deployed at the capacity bottleneck, but are
	often deployed in combination with other techniques, such as
	scheduling [RFC7567] [I-D.ietf-aqm-fq-codel] and although
	parameter-less methods are desired [RFC7567], current methods [I-D
	.ietf-aqm-fq-codel] [I-D.ietf-aqm-codel] [I-D.ietf-aqm-pie] often
	cannot scale across all possible deployment scenarios. The
	service offered by operators can therefore benefit from latency
	information to understand the impact of deployment and tune		information to understand the impact of deployment and tune
	deployed services.		deployed services. Latency metrics are key to evaluating and
			deploying AQM [RFC7567], DiffServ [RFC2474], and Explicit
			Congestion Notification (ECN) [RFC3168] [RFC8087]. Measurements
			could identify excessively large buffers, indicating where to
			deploy or configure AQM. An AQM method is often deployed in
			combination with other techniques, such as scheduling [RFC7567]
			[I-D.ietf-aqm-fq-codel] and although parameter-less methods are
			desired [RFC7567], current methods [I-D.ietf-aqm-fq-codel] [I-D
			.ietf-aqm-codel] [I-D.ietf-aqm-pie] often cannot scale across all
			possible deployment scenarios.
	Jitter: Some network applications are sensitive to changes in packet		Variation in delay: Some network applications are sensitive to small
	timing. For such applications, it can be necessary to measure the		changes in packet timing. To assess the performance of such
	jitter observed along a portion of the path. The requirements to		applications, it can be necessary to measure the variation in
	measure jitter resemble those for the measurement of latency.		delay observed along a portion of the path [RFC3393] [RFC5481].
			The requirements resemble those for the measurement of latency.
	Flow Reordering: Significant flow reordering can impact time-critical		Flow Reordering: Significant flow reordering can impact time-critical
	applications and can be interpreted as loss by reliable		applications and can be interpreted as loss by reliable
	transports. Many transport protocol techniques are impacted by		transports. Many transport protocol techniques are impacted by
	reordering (e.g., triggering TCP retransmission, or re-buffering		reordering (e.g., triggering TCP retransmission, or re-buffering
	of real-time applications). Packet reordering can occur for many		of real-time applications). Packet reordering can occur for many
	reasons (from equipment design to misconfiguration of forwarding		reasons (from equipment design to misconfiguration of forwarding
	rules). Since this impacts transport performance, network tools		rules). Since this impacts transport performance, network tools
	are needed to detect and measure unwanted/excessive reordering.		are needed to detect and measure unwanted/excessive reordering.
	As in the drive to reduce network latency, there is a need for
	operational tools to detect mis-ordered packet flows and quantify
	the degree or reordering. Techniques for measuring reordering
	typically observe packet sequence numbers. Metrics have been
	defined that evaluate whether a network has maintained packet
	order on a packet-by-packet basis [RFC4737] and [RFC5236].
	There have been initiatives in the IETF transport area to reduce		There have been initiatives in the IETF transport area to reduce
	the impact of reordering within a transport flow, possibly leading		the impact of reordering within a transport flow, possibly leading
	to reduce the requirements for ordering. These have promise to		to a reduction in the requirements for preserving ordering. These
	simplify network equipment design as well as the potential to		have promise to simplify network equipment design as well as the
	improve robustness of the transport service. Measurements of		potential to improve robustness of the transport service.
	reordering can help understand the level of reordering within		Measurements of reordering can help understand the present level
	deployed infrastructure, and inform decisions about how to		of reordering within deployed infrastructure, and inform decisions
	progress such mechanisms.		about how to progress such mechanisms.
	Some protocols provide in-built monitoring and reporting functions.		Operational tools to detect mis-ordered packet flows and quantify the
	Transport fields in the RTP header [RFC3550] [RFC4585] can be		degree or reordering. Key performance indicators are retransmission
	observed to derive traffic volume measurements and provide		rate, packet drop rate, sector utilisation level, a measure of
	information on the progress and quality of a session using RTP. Key		reordering, peak rate, the CE-marking rate, etc.
	performance indicators are retransmission rate, packet drop rate,
	sector utilisation level, a measure of reordering, peak rate, the CE-		Metrics have been defined that evaluate whether a network has
	marking rate, etc. Metadata is often important to understand the		maintained packet order on a packet-by-packet basis [RFC4737] and
			[RFC5236].
			Techniques for measuring reordering typically observe packet sequence
			numbers. Some protocols provide in-built monitoring and reporting
			functions. Transport fields in the RTP header [RFC3550] [RFC4585]
			can be observed to derive traffic volume measurements and provide
			information on the progress and quality of a session using RTP. As
			with other measurement, metadata is often important to understand the
	context under which the data was collected, including the time,		context under which the data was collected, including the time,
	observation point, and way in which metrics were accumulated. The		observation point, and way in which metrics were accumulated. The
	RTCP protocol directly reports some of this information in a form		RTCP protocol directly reports some of this information in a form
	that can be directly visible in the network. A user of summary		that can be directly visible in the network. A user of summary
	measurement data needs to trust the source of this data and the		measurement data needs to trust the source of this data and the
	method used to generate the summary information.		method used to generate the summary information.
	When information in transport headers is concealed, measurements need
	to rely on pattern inferences and other heuristics grows, and
	accuracy suffers [I-D.mm-wg-effect-encrypt].
	2.1.3. Metrics derived from Network Layer Headers		2.1.3. Metrics derived from Network Layer Headers
	Some transport information is made visible in the network-layer		Some transport information is made visible in the network-layer
	protocol header. These header fields are not encrypted and can be		protocol header. These header fields are not encrypted and can be
	used to make flow observations.		utilised to make flow observations.
	Use of IPv6 Network-Layer Flow Label: Endpoints are encouraged expose		Use of IPv6 Network-Layer Flow Label: Endpoints are encouraged expose
	flow information in the IPv6 Flow Label field of the network-layer		flow information in the IPv6 Flow Label field of the network-layer
	header (e.g., [RFC8085]). This can be used to inform network-layer		header (e.g., [RFC8085]). This can be used to inform network-layer
	queuing, forwarding (e.g., for equal cost multi-path (ECMP)		queuing, forwarding (e.g., for equal cost multi-path, ECMP,
	routing, and Link Aggregation, LAG). This can provide useful		routing, and Link Aggregation, LAG). This can provide useful
	information to assign packets to flows in the data collected by		information to assign packets to flows in the data collected by
	measurement campaigns. Although important to characterising a		measurement campaigns. Although important to characterising a
	path, it does not directly provide any performance data.		path, it does not directly provide performance data.
	Use Network-Layer Differentiated Services Code Point Point: Applicati		Use Network-Layer Differentiated Services Code Point Point: Applicati
	ons can expose their delivery expectations to the network by		ons can expose their delivery expectations to the network by
	setting the Differentiated Services Code Point (DSCP) field of		setting the Differentiated Services Code Point (DSCP) field of
	IPv4 and IPv6 packets. This can be used to inform network-layer		IPv4 and IPv6 packets. This can be used to inform network-layer
	queuing and forwarding, and can also provide information on the		queuing and forwarding, and can also provide information on the
	relative importance of packet information collected by measurement		relative importance of packet information collected by measurement
	campaigns, but does not directly provide any performance data.		campaigns, but does not directly provide performance data.
	This field provides explicit information that can be used in place		This field provides explicit information that can be used in place
	of inferring traffic requirements (e.g., by inferring QoS		of inferring traffic requirements (e.g., by inferring QoS
	requirements from port information via a multi-field classifier).		requirements from port information via a multi-field classifier).
	The DSCP value can therefore impact the quality of experience for		The DSCP value can therefore impact the quality of experience for
	a flow. Observations of service performance need to consider this		a flow. Observations of service performance need to consider this
	field when a network path has support for differentiated service		field when a network path has support for differentiated service
	treatment.		treatment.
	Use of Explicit Congestion Marking: ECN [RFC3168] is an optional		Use of Explicit Congestion Marking: ECN [RFC3168] is an optional
	skipping to change at page 13, line 34 ¶		skipping to change at page 13, line 43 ¶
	throughput, reduced delay, and other benefits when used over a		throughput, reduced delay, and other benefits when used over a
	path that includes equipment that supports an AQM method that		path that includes equipment that supports an AQM method that
	performs Congestion Experienced (CE) marking of IP packets		performs Congestion Experienced (CE) marking of IP packets
	[RFC8087].		[RFC8087].
	ECN exposes the presence of congestion on a network path to the		ECN exposes the presence of congestion on a network path to the
	transport and network layer. The reception of CE-marked packets		transport and network layer. The reception of CE-marked packets
	can therefore be used to monitor the presence and estimate the		can therefore be used to monitor the presence and estimate the
	level of incipient congestion on the upstream portion of the path		level of incipient congestion on the upstream portion of the path
	from the point of observation (Section 2.5 of [RFC8087]). Because		from the point of observation (Section 2.5 of [RFC8087]). Because
	ECN marks carried in the IP protocol header, it is much easier to		ECN marks are carried in the IP protocol header, it is much easier
	measure ECN than metering packet loss. However, interpreting the		to measure ECN than to measure packet loss. However, interpreting
	marking behaviour (i.e., assessing congestion and diagnosing		the marking behaviour (i.e., assessing congestion and diagnosing
	faults) requires context from the transport layer (path RTT,		faults) requires context from the transport layer (path RTT,
	visibility of loss - that could be due to queue overflow,		visibility of loss - that could be due to queue overflow,
	congestion response, etc) [RFC7567].		congestion response, etc) [RFC7567].
	Some ECN-capable network devices can provide richer (more frequent		Some ECN-capable network devices can provide richer (more frequent
	and fine-grained) indication of their congestion state. Setting		and fine-grained) indication of their congestion state. Setting
	congestion marks proportional to the level of congestion (e.g.,		congestion marks proportional to the level of congestion (e.g.,
	Data Center TCP, DCTP [RFC8257], and Low Latency Low Loss Scalable		Data Center TCP, DCTP [RFC8257], and Low Latency Low Loss Scalable
	throughput, L4S, [I-D.ietf-tsvwg-l4s-arch].		throughput, L4S, [I-D.ietf-tsvwg-l4s-arch].
	skipping to change at page 14, line 19 ¶		skipping to change at page 14, line 25 ¶
	increases and new methods emerge [RFC7567] [RFC8087]. ECN-		increases and new methods emerge [RFC7567] [RFC8087]. ECN-
	monitoring is expected to become important as AQM is deployed that		monitoring is expected to become important as AQM is deployed that
	supports ECN [RFC8087].		supports ECN [RFC8087].
	2.2. Transport Measurement		2.2. Transport Measurement
	The common language between network operators and application/content		The common language between network operators and application/content
	providers/users is packet transfer performance at a layer that all		providers/users is packet transfer performance at a layer that all
	can view and analyse. For most packets, this has been transport		can view and analyse. For most packets, this has been transport
	layer, until the emergence of QUIC, with the obvious exception of		layer, until the emergence of QUIC, with the obvious exception of
	VPNs and IPsec. When encryption conceals more layers in a packet,		Virtual Private Networks (VPNs) and IPsec.
	people seeking understanding of the network operation need to rely
	more on pattern inferences and other heuristics. The accuracy of		When encryption conceals more layers in each packet, people seeking
	measurements therefore suffers, as does the ability to investigate		understanding of the network operation rely more on pattern
	and troubleshoot interactions between different anomalies. For		inferences and other heuristics reliance on pattern inferences and
	example, the traffic patterns between a web server and a browser are		accuracy suffers. For example, the traffic patterns between server
	dependent on browser supplier and version, even use of the		and browser are dependent on browser supplier and version, even when
	application (e.g., web e-mail access). Even when measurement datasets		the sessions use the same server application (e.g., web e-mail
	are made available (e.g., from endpoints) additional metadata, such		access). It remains to be seen whether more complex inferences can be
	as the state of the network, is often required to interpret the data.		mastered to produce the same monitoring accuracy [I-D.mm-wg-effect-
	Collecting and coordinating such metadata is more difficult when the		encrypt].
	observation point is at a different location to the bottleneck/device
	under evaluation.		When measurement datasets are made available by servers or client
			endpoints, additional metadata, such as the state of the network, is
			often required to interpret this data. Collecting and coordinating
			such metadata is more difficult when the observation point is at a
			different location to the bottleneck/device under evaluation.
	Packet sampling techniques can be used to scale the processing		Packet sampling techniques can be used to scale the processing
	involved in observing packets on high rate links. This exports only		involved in observing packets on high rate links. This exports only
	the packet header information of (randomly) selected packets. The		the packet header information of (randomly) selected packets. The
	utility of these measurements depends on the type of bearer and		utility of these measurements depends on the type of bearer and
	number of mechanisms used by network devices. Simple routers are		number of mechanisms used by network devices. Simple routers are
	relatively easy to manage, a device with more complexity demands		relatively easy to manage, a device with more complexity demands
	understanding of the choice of many system parameters. This level of		understanding of the choice of many system parameters. This level of
	complexity exists when several network methods are combined.		complexity exists when several network methods are combined.
	skipping to change at page 15, line 17 ¶		skipping to change at page 15, line 18 ¶
	length (CODEL), flow-scheduling, and a starvation prevention		length (CODEL), flow-scheduling, and a starvation prevention
	mechanism. Usually such algorithms are designed to be self-tuning,		mechanism. Usually such algorithms are designed to be self-tuning,
	but current methods typically employ heuristics that can result in		but current methods typically employ heuristics that can result in
	more loss under certain path conditions (e.g., large RTT, effects of		more loss under certain path conditions (e.g., large RTT, effects of
	multiple bottlenecks [RFC7567]).		multiple bottlenecks [RFC7567]).
	In-network measurements can distinguish between upstream and		In-network measurements can distinguish between upstream and
	downstream metrics with respect to a measurement point. These are		downstream metrics with respect to a measurement point. These are
	particularly useful for locating the source of problems or to assess		particularly useful for locating the source of problems or to assess
	the performance of a network segment or a particular device		the performance of a network segment or a particular device
	configuration.		configuration. By correlating observations of headers at multiple
			points along the path (e.g., at the ingress and egress of a network
	By correlating observations of headers at multiple points along the		segment), an observer can determine the contribution of a portion of
	path (e.g., at the ingress and egress of a network segment), an		the path to an observed metric (to locate a source of delay, jitter,
	observer can determine the contribution of a portion of the path to		loss, reordering, congestion marking, etc.).
	an observed metric (to locate a source of delay, jitter, loss,
	reordering, congestion marking, etc.).
	2.2.2. Use by Operators to Plan and Provision Networks		2.2.2. Use by Operators to Plan and Provision Networks
	Traffic measurements (e.g., traffic volume, loss, latency) is used by		Traffic measurements (e.g., traffic volume, loss, latency) is used by
	operators to help plan deployment of new equipment and configurations		operators to help plan deployment of new equipment and configurations
	in their networks. Data is also important to equipment vendors who		in their networks. Data is also important to equipment vendors who
	need to understand traffic trends and patterns of usage as inputs to		need to understand traffic trends and patterns of usage as inputs to
	decisions about planning products and provisioning for new		decisions about planning products and provisioning for new
	deployments. This measurement information can also be correlated		deployments. This measurement information can also be correlated
	with billing information when this is also collected by an operator.		with billing information when this is also collected by an operator.
	A network operator supporting traffic that uses transport header		A network operator supporting traffic that uses transport header
	encryption may not have access to per-flow measurement data. Trends		encryption may not have access to per-flow measurement data. Trends
	in aggregate traffic can be observed and can be related this to the		in aggregate traffic can be observed and can be related to the
	endpoint addresses being used, but it may not be possible to		endpoint addresses being used, but it may not be possible to
	correlate patterns in measurements with changes in transport		correlate patterns in measurements with changes in transport
	protocols (e.g., the impact of changes in introducing a new transport		protocols (e.g., the impact of changes in introducing a new transport
	protocol mechanism). This increases the dependency on other indirect		protocol mechanism). This increases the dependency on other indirect
	sources of information to inform planning and provisioning.		sources of information to inform planning and provisioning.
	2.2.3. Service Performance Measurement		2.2.3. Service Performance Measurement
	Traffic measurements (e.g., traffic volume, loss, latency) can be		Traffic measurements (e.g., traffic volume, loss, latency) can be
	used by various actors to help analyse the performance offered to the		used by various actors to help analyse the performance offered to the
	skipping to change at page 16, line 24 ¶		skipping to change at page 16, line 24 ¶
	Information provided by tools observing transport headers can help		Information provided by tools observing transport headers can help
	determine whether mechanisms are needed in the network to prevent		determine whether mechanisms are needed in the network to prevent
	flows from acquiring excessive network capacity. Operators can		flows from acquiring excessive network capacity. Operators can
	implement operational practices to manage traffic flows (e.g., to		implement operational practices to manage traffic flows (e.g., to
	prevent flows from acquiring excessive network capacity under severe		prevent flows from acquiring excessive network capacity under severe
	congestion) by deploying rate-limiters, traffic shaping or network		congestion) by deploying rate-limiters, traffic shaping or network
	transport circuit breakers [RFC8084].		transport circuit breakers [RFC8084].
	Congestion Control Compliance of Traffic: Congestion control is a key		Congestion Control Compliance of Traffic: Congestion control is a key
	transport function. Many network operators implicitly accept that		transport function [RFC2914]. Many network operators implicitly
	TCP traffic to comply with a behaviour that is acceptable for use		accept that TCP traffic to comply with a behaviour that is
	in the shared Internet. TCP algorithms have been continuously		acceptable for use in the shared Internet. TCP algorithms have
	improved over decades, and they have reached a level of efficiency		been continuously improved over decades, and they have reached a
	and correctness that custom application-layer mechanisms will		level of efficiency and correctness that custom application-layer
	struggle to easily duplicate [RFC8085].		mechanisms will struggle to easily duplicate [RFC8085].
	A standards-compliant TCP stack provides congestion control may		A standards-compliant TCP stack provides congestion control may
	therefore be judged safe for use across the Internet.		therefore be judged safe for use across the Internet.
	Applications developed on top of well-designed transports can be		Applications developed on top of well-designed transports can be
	expected to appropriately control their network usage, reacting		expected to appropriately control their network usage, reacting
	when the network experiences congestion, by back-off and reduce		when the network experiences congestion, by back-off and reduce
	the load placed on the network. This is the normal expected		the load placed on the network. This is the normal expected
	behaviour for TCP and SCTP.		behaviour for IETF-specified transport (e.g., TCP and SCTP).
	However when anomalies are detected, tools can interpret the		However, when anomalies are detected, tools can interpret the
	transport protocol header information to help understand the		transport protocol header information to help understand the
	impact of specific transport protocols (or protocol mechanisms) on		impact of specific transport protocols (or protocol mechanisms) on
	the other traffic that shares a network. An observation in the		the other traffic that shares a network. An observation in the
	network can gain understanding of the dynamics of a flow and its		network can gain understanding of the dynamics of a flow and its
	congestion control behaviour. Analysing observed packet sequence		congestion control behaviour. Analysing observed packet sequence
	numbers can be used to help build confidence that an application		numbers can be used to help build confidence that an application
	flow backs-off its share of the network load in the face of		flow backs-off its share of the network load in the face of
	persistent congestion, and hence to understand whether the		persistent congestion, and hence to understand whether the
	behaviour is appropriate for sharing limited network capacity.		behaviour is appropriate for sharing limited network capacity.
	For example, it is common to visualise plots of TCP sequence		For example, it is common to visualise plots of TCP sequence
	numbers versus time for a flow to understand how a flow shares		numbers versus time for a flow to understand how a flow shares
	available capacity, deduce its dynamics in response to congestion,		available capacity, deduce its dynamics in response to congestion,
	etc.		etc.
	Congestion Control Compliance for UDP traffic UDP provides a minimal		Congestion Control Compliance for UDP traffic UDP provides a minimal
	message-passing transport that has no inherent congestion control		message-passing datagram transport that has no inherent congestion
	mechanisms. Because congestion control is critical to the stable		control mechanisms. Because congestion control is critical to the
	operation of the Internet, applications and other protocols that		stable operation of the Internet, applications and other protocols
	choose to use UDP as a transport are required to employ mechanisms		that choose to use UDP as a transport are required to employ
	to prevent congestion collapse, avoid unacceptable contributions		mechanisms to prevent congestion collapse, avoid unacceptable
	to jitter/latency, and to establish an acceptable share of		contributions to jitter/latency, and to establish an acceptable
	capacity with concurrent traffic [RFC8085].		share of capacity with concurrent traffic [RFC8085].
	A network operator needs tools to understand if UDP flows comply		A network operator needs tools to understand if datagram flows
	with congestion control expectations and therefore whether there		comply with congestion control expectations and therefore whether
	is a need to deploy methods such as rate-limiters, transport		there is a need to deploy methods such as rate-limiters, transport
	circuit breakers or other methods to enforce acceptable usage for		circuit breakers or other methods to enforce acceptable usage for
	the offered service.		the offered service.
	UDP flows that expose a well-known header by specifying the format		UDP flows that expose a well-known header by specifying the format
	of header fields can allow information to be observed to gain		of header fields can allow information to be observed to gain
	understanding of the dynamics of a flow and its congestion control		understanding of the dynamics of a flow and its congestion control
	behaviour. For example, tools exist to monitor various aspects of		behaviour. For example, tools exist to monitor various aspects of
	the RTP and RTCP header information of real-time flows (see		the RTP and RTCP header information of real-time flows (see
	Section 2.1.2.		Section 2.1.2.
	skipping to change at page 17, line 39 ¶		skipping to change at page 18, line 8 ¶
	Transport header information is useful for a variety of operational		Transport header information is useful for a variety of operational
	tasks [I-D.mm-wg-effect-encrypt]: to diagnose network problems,		tasks [I-D.mm-wg-effect-encrypt]: to diagnose network problems,
	assess performance, capacity planning, management of denial of		assess performance, capacity planning, management of denial of
	service threats, and responding to user performance questions. These		service threats, and responding to user performance questions. These
	tasks seldom involve the need to determine the contents of the		tasks seldom involve the need to determine the contents of the
	transport payload, or other application details.		transport payload, or other application details.
	A network operator supporting traffic that uses transport header		A network operator supporting traffic that uses transport header
	encryption can see only encrypted transport headers. This prevents		encryption can see only encrypted transport headers. This prevents
	deployment of performance measurement tools that rely on transport		deployment of performance measurement tools that rely on transport
	protocol information. Choosing to encrypt all information may be		protocol information. Choosing to encrypt all information may reduce
	expected to reduce the ability for networks to "help" (e.g., in		the ability for networks to "help" (e.g., in response to tracing
	response to tracing issues, making appropriate Quality of Service,		issues, making appropriate QoS decisions). For some this will be
	QoS, decisions). For some this will be blessing, for others it may be		blessing, for others it may be a curse. For example, operational
	a curse. For example, operational performance data about encrypted		performance data about encrypted flows needs to be determined by
	flows needs to be determined by traffic pattern analysis, rather than		traffic pattern analysis, rather than relying on traditional tools.
	relying on traditional tools. This can impact the ability of the		This can impact the ability of the operator to respond to faults, it
	operator to respond to faults, it could require reliance on endpoint		could require reliance on endpoint diagnostic tools or user
	diagnostic tools or user involvement in diagnosing and		involvement in diagnosing and troubleshooting unusual use cases or
	troubleshooting unusual use cases or non-trivial problems. A key		non-trivial problems. A key need here is for tools to provide useful
	need here is that tools need to provide useful information during		information during network anomalies (e.g., significant reordering,
	network anomalies (e.g., significant reordering, high or intermittent		high or intermittent loss). Although many network operators utilise
	loss). Although many network operators utilise transport information		transport information as a part of their operational practice, the
	as a part of their operational practice, the network will not break		network will not break because transport headers are encrypted, and
	because transport headers are encrypted.		this may require alternative tools may need to be developed and
			deployed.
	2.3.1. Examples of measurements		2.3.1. Examples of measurements
	Future versions of this document may provide more about existing
	tooling at Network Operations Centres that rely upon observing
	transport layer header information.
	Debugging and diagnosing the root causes of faults concern particular		Measurements can be used to monitor the health of a portion of the
	users traffic is an activity that may depend on connection		Internet, to provide early warning of the need to take action. They
	information from the protocol - In some case, this may involve active		can assist in debugging and diagnosing the root causes of faults that
	injection of test traffic to complete a measurement. Most operators		concern a particular user's traffic. They can also be used to
	do not have access to user equipment. There may also be costs		support post-mortem inverstigation after an anompoly to determine the
	associated with running such tests (e.g., the implications of		root cause of a problem.
	bandwidth tests in a mobile network are obvious). Some active
	measurements (e.g., response under load or particular workloads) may		In some case, measurements may involve active injection of test
			traffic to complete a measurement. However, most operators do not
			have access to user equipment, and injection of test traffic may be
			associated with costs in running such tests (e.g., the implications
			of bandwidth tests in a mobile network are obvious). Some active
			measurements (e.g., response under load or particular workloads)
	perturb other traffic, and could require dedicated access to the		perturb other traffic, and could require dedicated access to the
	network segment. An alternative approach is to use in-network		network segment. An alternative approach is to use in-network
	techniques that observe transport packet headers in operational		techniques that observe transport packet headers in operational
	networks to make the measurements.		networks to make the measurements.
	in other cases, measurement involves dissecting traffic flows. The		In other cases, measurement involves dissecting network traffic
	observed transport layer information can help identify whether the		flows. The observed transport layer information can help identify
	link/network tuning is effective and alert to potential problems that		whether the link/network tuning is effective and alert to potential
	can be hard to derive from link or device measurements alone. The		problems that can be hard to derive from link or device measurements
	design trade-offs for radio networks are often very different to		alone. The design trade-offs for radio networks are often very
	those of wired networks. A radio-based network (e.g., cellular		different to those of wired networks. A radio-based network (e.g.,
	mobile, enterprise WiFi, satellite access/back-haul, point-to-point		cellular mobile, enterprise WiFi, satellite access/back-haul, point-
	radio) has the complexity of a subsystem that performs radio resource		to-point radio) has the complexity of a subsystem that performs radio
	management - with direct impact on the available capacity, and		resource management,s with direct impact on the available capacity,
	potentially loss/reordering of packets. The impact of the pattern of		and potentially loss/reordering of packets. The impact of the
	loss and congestion, differs for different traffic types, correlation		pattern of loss and congestion, differs for different traffic types,
	with propagation and interference can all have significant impact on		correlation with propagation and interference can all have
	the cost and performance of a provided service. The need for this		significant impact on the cost and performance of a provided service.
	type of information is expected to increase as operators bring		The need for this type of information is expected to increase as
	together heterogeneous types of network equipment and seek to deploy		operators bring together heterogeneous types of network equipment and
	opportunistic methods to access radio spectrum.		seek to deploy opportunistic methods to access radio spectrum.
	XXX Note: The authors are looking for contributions that say more
	about the things people are currently doing with exposed transport
	fields and what problems they are trying to solve, or how they use
	the information they derive. How problematic is new tools to follow-
	up. Examples could include: Health monitoring; anomoly/DoS
	detection; Capacity planning, etc XXX
	2.4. Observing Headers to Implement Network Policy		2.4. Observing Headers to Implement Network Policy
	Information from the transport protocol can be used by a multi-field		Information from the transport protocol can be used by a multi-field
	classifier as a part of policy framework. Policies are commonly used		classifier as a part of policy framework. Policies are commonly used
	for QoS management for resource-constrained networks and by firewalls		for management of the QoS or Quality of Experience (QoE) in resource-
	that use the information to implement access rules. Traffic that		constrained networks and by firewalls that use the information to
	cannot be classified, will typically receive a default treatment.		implement access rules. Traffic that cannot be classified, will
			typically receive a default treatment.
	3. Encryption and Authentication of Transport Headers		3. Encryption and Authentication of Transport Headers
	End-to-end encryption can be applied at various protocol layers. It		End-to-end encryption can be applied at various protocol layers. It
	can be applied above the transport to encrypt the transport payload.		can be applied above the transport to encrypt the transport payload.
	Encryption methods can hide information from an eavesdropper in the		Encryption methods can hide information from an eavesdropper in the
	network. Encryption can also help protect the privacy of a user, by		network. Encryption can also help protect the privacy of a user, by
	hiding data relating to user/device identity or location. Neither an		hiding data relating to user/device identity or location. Neither an
	integrity check nor encryption methods prevent traffic analysis, and		integrity check nor encryption methods prevent traffic analysis, and
	usage needs to reflect that profiling of users, identification of		usage needs to reflect that profiling of users, identification of
	location and fingerprinting of behaviour can take place even on		location and fingerprinting of behaviour can take place even on
	encrypted traffic flows.		encrypted traffic flows.
	skipping to change at page 19, line 14 ¶		skipping to change at page 19, line 43 ¶
	End-to-end encryption can be applied at various protocol layers. It		End-to-end encryption can be applied at various protocol layers. It
	can be applied above the transport to encrypt the transport payload.		can be applied above the transport to encrypt the transport payload.
	Encryption methods can hide information from an eavesdropper in the		Encryption methods can hide information from an eavesdropper in the
	network. Encryption can also help protect the privacy of a user, by		network. Encryption can also help protect the privacy of a user, by
	hiding data relating to user/device identity or location. Neither an		hiding data relating to user/device identity or location. Neither an
	integrity check nor encryption methods prevent traffic analysis, and		integrity check nor encryption methods prevent traffic analysis, and
	usage needs to reflect that profiling of users, identification of		usage needs to reflect that profiling of users, identification of
	location and fingerprinting of behaviour can take place even on		location and fingerprinting of behaviour can take place even on
	encrypted traffic flows.		encrypted traffic flows.
	One motive to use encryption is a response to perceptions that the		There are several motivations:
	network has become ossified by over-reliance on middleboxes that
	prevent new protocols and mechanisms from being deployed. This has
	lead to a common perception that there is too much "manipulation" of
	protocol headers within the network, and that designing to deploy in
	such networks is preventing transport evolution. In the light of
	this, a method that authenticates transport headers may help improve
	the pace of transport development, by eliminating the need to always
	consider deployed middleboxes [I-D.trammell-plus-abstract-mech], or
	potentially to only explicitly enable middlebox use for particular
	paths with particular middleboxes that are deliberately deployed to
	realise a useful function for the network and/or users[RFC3135].
	Another motivation stems from increased concerns about privacy and		o One motive to use encryption is a response to perceptions that the
	surveillance. Some Internet users have valued the ability to protect		network has become ossified by over-reliance on middleboxes that
	identity, user location, and defend against traffic analysis, and		prevent new protocols and mechanisms from being deployed. This
	have used methods such as IPsec ESP. Revelations about the use of		has lead to a perception that there is too much "manipulation" of
	pervasive surveillance [RFC7624] have, to some extent, eroded trust		protocol headers within the network, and that designing to deploy
	in the service offered by network operators, and following the		in such networks is preventing transport evolution. In the light
	Snowden revelation in the USA in 2013 has led to an increased desire		of this, a method that authenticates transport headers may help
	for people to employ encryption to avoid unwanted "eavesdropping" on		improve the pace of transport development, by eliminating the need
	their communications. Whatever the reasons, there are now activities		to always consider deployed middleboxes [I-D.trammell-plus-
	in the IETF to design new protocols that may include some form of		abstract-mech], or potentially to only explicitly enable middlebox
	transport header encryption (e.g., QUIC [I-D.ietf-quic-transport]).		use for particular paths with particular middleboxes that are
			deliberately deployed to realise a useful function for the network
			and/or users[RFC3135].
			o Another motivation stems from increased concerns about privacy and
			surveillance. Some Internet users have valued the ability to
			protect identity, user location, and defend against traffic
			analysis, and have used methods such as IPsec ESP. Revelations
			about the use of pervasive surveillance [RFC7624] have, to some
			extent, eroded trust in the service offered by network operators,
			and following the Snowden revelation in the USA in 2013 has led to
			an increased desire for people to employ encryption to avoid
			unwanted "eavesdropping" on their communications. Concerns have
			also been voiced about the addition of information to packets by
			third parties to provide analytics, customization, advertising,
			cross-site tracking of users, to bill the customer, or to
			selectively allow or block content. Whatever the reasons, there
			are now activities in the IETF to design new protocols that may
			include some form of transport header encryption (e.g., QUIC [I-D
			.ietf-quic-transport]).
	Authentication methods (that provide integrity checks of protocols		Authentication methods (that provide integrity checks of protocols
	fields) have also been specified at the network layer, and this also		fields) have also been specified at the network layer, and this also
	protects transport header fields. The network layer itself carries		protects transport header fields. The network layer itself carries
	protocol header fields that are increasingly used to help forwarding		protocol header fields that are increasingly used to help forwarding
	decisions reflect the need of transport protocols, such the IPv6 Flow		decisions reflect the need of transport protocols, such as the IPv6
	Label [RFC6437], the DSCP and ECN.		Flow Label [RFC6437], the DSCP and ECN.
	The use of transport layer authentication and encryption exposes a		The use of transport layer authentication and encryption exposes a
	tussle between middlebox vendors, operators, applications developers		tussle between middlebox vendors, operators, applications developers
	and users.		and users.
	o On the one hand, future Internet protocols that enable large-scale		o On the one hand, future Internet protocols that enable large-scale
	encryption assist in the restoration of the end-to-end nature of		encryption assist in the restoration of the end-to-end nature of
	the Internet by returning complex processing to the endpoints,		the Internet by returning complex processing to the endpoints,
	since middleboxes cannot modify what they cannot see.		since middleboxes cannot modify what they cannot see.
	skipping to change at page 21, line 22 ¶		skipping to change at page 22, line 15 ¶
	3.4. Authenticating Transport Information and Selectively Encrypting		3.4. Authenticating Transport Information and Selectively Encrypting
	the Transport Header		the Transport Header
	A transport protocol design can encrypt selected header fields, while		A transport protocol design can encrypt selected header fields, while
	also choosing to authenticate fields in the transport header. This		also choosing to authenticate fields in the transport header. This
	allows specific transport header fields to be made observable by		allows specific transport header fields to be made observable by
	network devices. End-to end integrity checks can prevent an endpoint		network devices. End-to end integrity checks can prevent an endpoint
	from undetected modification of the immutable transport headers.		from undetected modification of the immutable transport headers.
	The choice of which fields to expose and which to encrypt is a design
	choice for the transport protocol. Any selective encryption method
	requires trading two conflicting goals for a transport protocol
	designer to decide which header fields to encrypt. On the one hand,
	security work typically employs a design technique that seeks to
	expose only what is needed. On the other hand, there may be
	performance and operational benefits in exposing selected information
	to network tools.
	Mutable fields in the transport header provide opportunities for		Mutable fields in the transport header provide opportunities for
	middleboxes to modify the transport behaviour (e.g., the extended		middleboxes to modify the transport behaviour (e.g., the extended
	headers described in [I-D.trammell-plus-abstract-mech]). This		headers described in [I-D.trammell-plus-abstract-mech]). This
	considers only immutable fields in the transport headers, that is,		considers only immutable fields in the transport headers, that is,
	fields that may be authenticated End-to-End across a path.		fields that may be authenticated End-to-End across a path.
	An example of a method that encrypts some, but not all, transport		An example of a method that encrypts some, but not all, transport
	information is GRE-in-UDP [RFC8086] when used with GRE encryption.		information is GRE-in-UDP [RFC8086] when used with GRE encryption.
	3.5. Optional Encryption of Header Information		3.5. Optional Encryption of Header Information
	skipping to change at page 21, line 52 ¶		skipping to change at page 22, line 36 ¶
	There are implications to the use of optional header encryption in		There are implications to the use of optional header encryption in
	the design of a transport protocol, where support of optional		the design of a transport protocol, where support of optional
	mechanisms can increase the complexity of the protocol and its		mechanisms can increase the complexity of the protocol and its
	implementation and in the management decisions that are required to		implementation and in the management decisions that are required to
	use variable format fields. Instead, fields of a specific type ought		use variable format fields. Instead, fields of a specific type ought
	to always be sent with the same level of confidentiality or integrity		to always be sent with the same level of confidentiality or integrity
	protection.		protection.
	4. Addition of Transport Information to Network-Layer Protocol Headers		4. Addition of Transport Information to Network-Layer Protocol Headers
	The transport information can be made visible in a network-layer		Transport protocol information can be made visible in a network-layer
	header. This has the advantage that this information can then be		header. This has the advantage that this information can then be
	observed by in-network devices. This has the advantage that a single		observed by in-network devices. This has the advantage that a single
	header can support all transport protocols, but there may also be		header can support all transport protocols, but there may also be
	less desirable implications of separating the operation of the		less desirable implications of separating the operation of the
	transport protocol from the measurement framework.		transport protocol from the measurement framework.
	Some measurements may be made by adding additional protocol headers		Some measurements may be made by adding additional protocol headers
	carrying operations, administration and management (OAM) information		carrying operations, administration and management (OAM) information
	to packets at the ingress to a maintenance domain (e.g., an Ethernet		to packets at the ingress to a maintenance domain (e.g., an Ethernet
	protocol header with timestamps and sequence number information using		protocol header with timestamps and sequence number information using
	skipping to change at page 22, line 28 ¶		skipping to change at page 23, line 19 ¶
	Another example of a network-layer approach is the IPv6 Performance		Another example of a network-layer approach is the IPv6 Performance
	and Diagnostic Metrics (PDM) Destination Option [I-D.ietf-ippm-6man-		and Diagnostic Metrics (PDM) Destination Option [I-D.ietf-ippm-6man-
	pdm-option]. This allows a sender to optionally include a		pdm-option]. This allows a sender to optionally include a
	destination option that caries header fields that can be used to		destination option that caries header fields that can be used to
	observe timestamps and packet sequence numbers. This information		observe timestamps and packet sequence numbers. This information
	could be authenticated by receiving transport endpoints when the		could be authenticated by receiving transport endpoints when the
	information is added at the sender and visible at the receiving		information is added at the sender and visible at the receiving
	endpoint, although methods to do this have not currently been		endpoint, although methods to do this have not currently been
	proposed. This method needs to be explicitly enabled at the sender.		proposed. This method needs to be explicitly enabled at the sender.
	It can be undesirable to rely on methods requiring options or		It can be undesirable to rely on methods requiring the presence of
	extension headers. IPv4 network options are often not supported (or		network options or extension headers. IPv4 network options are often
	are carried on a slower processing path) and some IPv6 networks are		not supported (or are carried on a slower processing path) and some
	also known to drop packets that set an IPv6 header extension (e.g.,		IPv6 networks are also known to drop packets that set an IPv6 header
	[RFC7872]). Another disadvantage is that protocols that separately		extension (e.g., [RFC7872]). Another disadvantage is that protocols
	expose header information do not necessarily have an advantage to		that separately expose header information do not necessarily have an
	expose the information that is utilised by the protocol itself, and		advantage to expose the information that is utilised by the protocol
	could manipulate this header information to gain an advantage from		itself, and could manipulate this header information to gain an
	the network.		advantage from the network.
	5. Implications of Protecting the Transport Headers		5. Implications of Protecting the Transport Headers
			The choice of which fields to expose and which to encrypt is a design
			choice for the transport protocol. Any selective encryption method
			requires trading two conflicting goals for a transport protocol
			designer to decide which header fields to encrypt. Security work
			typically employs a design technique that seeks to expose only what
			is needed. However, there can be performance and operational
			benefits in exposing selected information to network tools.
	This section explores key implications of working with encrypted		This section explores key implications of working with encrypted
	transport protocols.		transport protocols.
	5.1. Independent Measurement		5.1. Independent Measurement
	Independent observation by multiple actors is important for		Independent observation by multiple actors is important for
	scientific analysis. Encrypting transport header encryption changes		scientific analysis. Encrypting transport header encryption changes
	the ability for other actors to collect and independently analyse		the ability for other actors to collect and independently analyse
	data. Internet transport protocols employ a set of mechanisms. Some		data. Internet transport protocols employ a set of mechanisms. Some
	of these need to work in cooperation with the network layer - loss		of these need to work in cooperation with the network layer - loss
	detection and recovery, congestion detection and congestion control,		detection and recovery, congestion detection and congestion control,
	some of these need to work only End-to-End (e.g., parameter		some of these need to work only End-to-End (e.g., parameter
	negotiation, flow-control).		negotiation, flow-control).
	When encryption conceals information in the transport header, it		When encryption conceals information in the transport header, it
	could be possible for an applications to provide summary data on		could be possible for an applications to provide summary data on
	performance and usage of the network. This data could be made		performance and usage of the network. This data could be made
	available to other actors. However, this data needs to contain		available to other actors. However, this data needs to contain
	sufficient detail to understand (and possibly reconstruct the network		sufficient detail to understand (and possibly reconstruct the network
	traffic pattern for further testing) and to be correlated with the		traffic pattern for further testing) and to be correlated with the
	configuration of the network paths being measured. Sharing		configuration of the network paths being measured.
	information between actors needs also to consider the privacy of the
	user and the incentives for providing accurate and detailed		Sharing information between actors needs also to consider the privacy
			of the user and the incentives for providing accurate and detailed
	information. Protocols that expose the state information used by the		information. Protocols that expose the state information used by the
	transport protocol in their header information (e.g., timestamps used		transport protocol in their header information (e.g., timestamps used
	to calculate the RTT, packet numbers used to asses congestion and		to calculate the RTT, packet numbers used to asses congestion and
	requests for retransmission) provide an incentive for the sending		requests for retransmission) provide an incentive for the sending
	endpoint to provide correct information, increasing confidence that		endpoint to provide correct information, increasing confidence that
	the observer understands the transport interaction with the network.		the observer understands the transport interaction with the network.
	This becomes important when considering changes to transport		This becomes important when considering changes to transport
	protocols, changes in network infrastructure, or the emergence of new		protocols, changes in network infrastructure, or the emergence of new
	traffic patterns.		traffic patterns.
	skipping to change at page 24, line 6 ¶		skipping to change at page 25, line 15 ¶
	5.3. Accountability and Internet Transport Protocols		5.3. Accountability and Internet Transport Protocols
	Information provided by tools observing transport headers can help		Information provided by tools observing transport headers can help
	determine whether mechanisms are needed in the network to prevent		determine whether mechanisms are needed in the network to prevent
	flows from acquiring excessive network capacity, and where needed to		flows from acquiring excessive network capacity, and where needed to
	deploy appropriate tools Section 2.2.4. Obfuscating or hiding this		deploy appropriate tools Section 2.2.4. Obfuscating or hiding this
	information using encryption is expected to lead operators and		information using encryption is expected to lead operators and
	maintainers of middleboxes (firewalls, etc.) to seek other methods to		maintainers of middleboxes (firewalls, etc.) to seek other methods to
	classify and mechanisms to condition network traffic.		classify and mechanisms to condition network traffic.
	A lack of data seems likely to reduce the level of precision with		A lack of data reduces the level of precision with which mechanisms
	which these mechanisms are applied, and this needs to be considered		are applied, and this needs to be considered when evaluating the
	when evaluating the impact of designs for transport encryption. This		impact of designs for transport encryption. This could lead to
	could lead to increased use of rate limiting, circuit breaker		increased use of rate limiting, circuit breaker techniques [RFC8084],
	techniques [RFC8084], or even blocking of uncharacterised traffic.		or even blocking of uncharacterised traffic. This would hinder
	This would hinder deployment of new mechanisms and/or protocols.		deployment of new mechanisms and/or protocols.
	5.4. Impact on Research, Development and Deployment		5.4. Impact on Research, Development and Deployment
	There are both opportunities and also challenges to the design,		The majority of present Internet applications use two well-known
	evaluation and deployment of new transport protocol mechanisms.		transport protocols: e.g., TCP and UDP. Although TCP represents the
			majority of current traffic, some important real-time applications
			use UDP, and much of this traffic utilises RTP format headers in the
			payload of the UDP datagram. Since these protocol headers have been
			fixed for decades, a range of tools and analysis methods have became
			common and well-understood. Over this period, the transport protocol
			headers have mostly changed slowly, and so also the need to develop
			tools track new versions of the protocol.
	Integrity checks can avoiding network devices undetected modification		Looking ahead, there will be a need to update these protocols and to
	of protocols, whereas encryption and obfuscation can prevent these		develop and deploy new transport mechanisms and protocols. There are
	headers being utilised by network devices. This provides greater		both opportunities and also challenges to the design, evaluation and
	freedom to update the protocols and can therefore ease		deployment of new transport protocol mechanisms.
	experimentation with new techniques and their final deployment in
	endpoints.
	Measurement data is increasingly being used to inform design		Integrity checks can undetected modification of protocol fields by
	decisions in networking research, during development of new		network devices, whereas encryption and obfuscation can further
			prevent these headers being utilised by network devices. Hiding
			headers can therefore provide the opportunity for greater freedom to
			update the protocols and can ease experimentation with new techniques
			and their final deployment in endpoints.
			Hiding headers can limit the ability to measure and characterise
			traffic. Measurement data is increasingly being used to inform
			design decisions in networking research, during development of new
	mechanisms and protocols and in standardisation. Measurement has a		mechanisms and protocols and in standardisation. Measurement has a
	critical role in the design of transport protocol mechanisms and		critical role in the design of transport protocol mechanisms and
	their acceptance by the wider community (e.g., as a method to judge		their acceptance by the wider community (e.g., as a method to judge
	the safety for Internet deployment). Observation of pathologies are		the safety for Internet deployment). Observation of pathologies are
	also important in understanding the interactions between cooperating		also important in understanding the interactions between cooperating
	protocols and network mechanism, the implications of sharing capacity		protocols and network mechanism, the implications of sharing capacity
	with other traffic and the impact of different patterns of usage.		with other traffic and the impact of different patterns of usage.
	Attention needs to be paid to the expected scale of deployment of new		Evolution and the ability to understand (measure) the impact need to
	protocols and protocol mechanisms. Whatever the mechanism,		proceed hand-in-hand. Attention needs to be paid to the expected
	experience has shown that it is often difficult to correctly		scale of deployment of new protocols and protocol mechanisms.
	implement combination of mechanisms [RFC8085]. These mechanisms		Whatever the mechanism, experience has shown that it is often
	therefore typically evolve as a protocol matures, or in response to		difficult to correctly implement combination of mechanisms [RFC8085].
	changes in network conditions, changes in network traffic or changes		These mechanisms therefore typically evolve as a protocol matures, or
	to application usage.		in response to changes in network conditions, changes in network
			traffic or changes to application usage.
	New transport protocol formats are expected to facilitate an		New transport protocol formats are expected to facilitate an
	increased pace of transport evolution, and with it the possibility to		increased pace of transport evolution, and with it the possibility to
	experiment with and deploy a wide range of protocol mechanisms.		experiment with and deploy a wide range of protocol mechanisms.
	There has been recent interest in a wide range of new transport		There has been recent interest in a wide range of new transport
	methods, e.g., Larger Initial Window, Proportional Rate Reduction		methods, e.g., Larger Initial Window, Proportional Rate Reduction
	(PRR), congestion control methods based on measuring bottleneck		(PRR), congestion control methods based on measuring bottleneck
	bandwidth and round-trip propagation time, the introduction of AQM		bandwidth and round-trip propagation time, the introduction of AQM
	techniques and new forms of ECN response (e.g., DCTP, and methods		techniques and new forms of ECN response (e.g., Data Centre TCP,
	proposed for L4S).The growth and diversity of applications and		DCTP, and methods proposed for L4S).The growth and diversity of
	protocols using the Internet also continues to expand. For each new		applications and protocols using the Internet also continues to
	method or application it is desirable to build a body of data		expand. For each new method or application it is desirable to build
	reflecting its behaviour under a wide range of deployment scenarios,		a body of data reflecting its behaviour under a wide range of
	traffic load, and interactions with other deployed/candidate methods.		deployment scenarios, traffic load, and interactions with other
			deployed/candidate methods.
	Open standards motivate a desire for this evaluation to include		Open standards motivate a desire for this evaluation to include
	independent observation and evaluation of performance data, which in		independent observation and evaluation of performance data, which in
	turn suggests control over where and when measurement samples are		turn suggests control over where and when measurement samples are
	collected. This requires consideration of the appropriate balance		collected. This requires consideration of the appropriate balance
	between encrypting all and no transport information.		between encrypting all and no transport information.
	6. Conclusions		6. Conclusions
	XXX Notes for a draft conclusion XXX		The majority of present Internet applications use two well-known
			transport protocols: e.g., TCP and UDP. Although TCP represents the
	The majority of traffic sent by the present Internet uses two well-		majority of current traffic, some important real-time applications
	known transport protocols: e.g., TCP and UDP.		have used UDP, and much of this traffic utilises RTP format headers
			in the payload of the UDP datagram. Since these protocol headers
	Although TCP represents the majority of current traffic, some		have been fixed for decades, a range of tools and analysis methods
	important real-time applications have used UDP, and much of this		have became common and well-understood. Over this period, the
	traffic utilises RTP format headers in the payload of the UDP data.		transport protocol headers have mostly changed slowly, and so also
	Since these protocol headers have been fixed for decades, a range of		the need to develop tools track new versions of the protocol.
	tools and analysis methods have became common and well-understood.
	Over this period, the transport protocol headers have mostly changed
	slowly, and so also the need to develop tools track new versions of
	the protocol.
	Encryption (confidentiality and strong integrity checks) have		Confidentiality and strong integrity checks have properties that are
	properties that are being incorporated into new protocols and which		being incorporated into new protocols and which have important
	have important benefits. The pace of development of transports using		benefits. The pace of development of transports using the WebRTC
	the WebRTC data channel and the rapid deployment of QUIC prototype		data channel and the rapid deployment of QUIC prototype transports
	transports can both be attributed to using a combination of UDP		can both be attributed to using a combination of UDP transport and
	transport and encryption of the UDP payload.		confidentiality of the UDP payload.
	The traffic that can be observed by devices in a network is a		The traffic that can be observed by devices in a network is a
	function of transport protocol design/options, network use,		function of transport protocol design/options, network use,
	applications and user characteristics. In general, when only a small		applications and user characteristics. In general, when only a small
	proportion of the traffic has a specific (different) characteristic.		proportion of the traffic has a specific (different) characteristic.
	Such traffic seldom leads to an operational issue although the		Such traffic seldom leads to an operational issue although the
	ability to measure and monitor it is less. The desire to understand		ability to measure and monitor it is less. The desire to understand
	the traffic and protocol interactions typically grows as the		the traffic and protocol interactions typically grows as the
	proportion of traffic increases in volume. The challenges increase		proportion of traffic increases in volume. The challenges increase
	when multiple instances of an evolving protocol contribute to the		when multiple instances of an evolving protocol contribute to the
	skipping to change at page 26, line 44 ¶		skipping to change at page 28, line 25 ¶
	protocol information (preventing observation within the network).		protocol information (preventing observation within the network).
	The transport information can be used by operators to provide		The transport information can be used by operators to provide
	troubleshooting, easement and any necessary functions for the		troubleshooting, easement and any necessary functions for the
	class of traffic (priority, retransmission, reordering, circuit		class of traffic (priority, retransmission, reordering, circuit
	breakers, etc).		breakers, etc).
	o An alternative scenario adopts different design goals, with a		o An alternative scenario adopts different design goals, with a
	different outcome. A protocol that encrypts all header		different outcome. A protocol that encrypts all header
	information forces network operators to act independently from		information forces network operators to act independently from
	apps/transport developments to provide the transport information		apps/transport developments to provide the transport information
	they need. A range of approaches may proliferate - as in current		they need. A range of approaches may proliferate, as in current
	networks, operators can add a shim header to each packet as a flow		networks, operators can add a shim header to each packet as a flow
	as it crosses the network ; other operators/managers could develop		as it crosses the network; other operators/managers could develop
	heuristics and pattern recognition to derive information that		heuristics and pattern recognition to derive information that
	classifies flows and estimates quality metrics for the service		classifies flows and estimates quality metrics for the service
	being used; some could decide to rate-limit or block traffic until		being used; some could decide to rate-limit or block traffic until
	new tooling is in place. In many cases, the derived information		new tooling is in place. In many cases, the derived information
	can be used by operators to provide necessary functions for the		can be used by operators to provide necessary functions
	class of traffic (priority, retransmission, reordering, circuit		appropriate to the class of traffic (priority, retransmission,
	breakers, etc). Troubleshooting, and measurement becomes more		reordering, circuit breakers, etc). Troubleshooting, and
	difficult or could require additional information. In some cases,		measurement becomes more difficult, and more diverse. This could
	operators might need access to keying information to interpret		require additional information beyond that visible in the packet
	encrypted data that they observe. Some use cases could demand use		header and. In some cases, operators might need access to keying
	of transports that do not use encryption.		information to interpret encrypted data that they observe. Some
			use cases could demand use of transports that do not use
			encryption.
	The outcome could have significant implications on the way the		The outcome could have significant implications on the way the
	Internet architecture develops. It exposes a risk that significant		Internet architecture develops. It exposes a risk that significant
	actors (e.g., developers and transport designers) achieve more		actors (e.g., developers and transport designers) achieve more
	control of the way in which the Internet architecture develops.In		control of the way in which the Internet architecture develops.In
	particular, there is a possibility that designs could evolve to		particular, there is a possibility that designs could evolve to
	significantly benefit of customers for a specific vendor, and that		significantly benefit of customers for a specific vendor, and that
	communities with very different network, applications or platforms		communities with very different network, applications or platforms
	could then suffer at the expense of benefits to their vendors own		could then suffer at the expense of benefits to their vendors own
	customer base. In such a scenario, there could be no incentive to		customer base. In such a scenario, there could be no incentive to
	skipping to change at page 28, line 19 ¶		skipping to change at page 30, line 4 ¶
	rfc2119>.		rfc2119>.
	10.2. Informative References		10.2. Informative References
	[I-D.dolson-plus-middlebox-benefits]		[I-D.dolson-plus-middlebox-benefits]
	Dolson, D., Snellman, J., Boucadair, M. and C. Jacquenet,		Dolson, D., Snellman, J., Boucadair, M. and C. Jacquenet,
	"Beneficial Functions of Middleboxes", Internet-Draft		"Beneficial Functions of Middleboxes", Internet-Draft
	draft-dolson-plus-middlebox-benefits-03, March 2017.		draft-dolson-plus-middlebox-benefits-03, March 2017.
	[I-D.ietf-aqm-codel]		[I-D.ietf-aqm-codel]
	Nichols, K., Jacobson, V., McGregor, A. and J. Jana,		Nichols, K., Jacobson, V., McGregor, A. and J. Iyengar,
	"Controlled Delay Active Queue Management", Internet-Draft		"Controlled Delay Active Queue Management", Internet-Draft
	draft-ietf-aqm-codel-00, October 2014.		draft-ietf-aqm-codel-10, October 2017.
	[I-D.ietf-aqm-fq-codel]		[I-D.ietf-aqm-fq-codel]
	Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys,		Hoeiland-Joergensen, T., McKenney, P.,
	J. and E. Dumazet, "FlowQueue-Codel", Internet-Draft		dave.taht@gmail.com, d., Gettys, J. and E. Dumazet, "The
	draft-ietf-aqm-fq-codel-00, January 2015.		FlowQueue-CoDel Packet Scheduler and Active Queue
			Management Algorithm", Internet-Draft draft-ietf-aqm-fq-
			codel-06, March 2016.
	[I-D.ietf-aqm-pie]		[I-D.ietf-aqm-pie]
	Pan, R., Natarajan, P., Baker, F. and G. White, "PIE: A		Pan, R., Natarajan, P., Baker, F. and G. White, "PIE: A
	Lightweight Control Scheme To Address the Bufferbloat		Lightweight Control Scheme To Address the Bufferbloat
	Problem", Internet-Draft draft-ietf-aqm-pie-00, October		Problem", Internet-Draft draft-ietf-aqm-pie-10, September
	2014.		2016.
	[I-D.ietf-ippm-6man-pdm-option]		[I-D.ietf-ippm-6man-pdm-option]
	Elkins, N., Hamilton, R. and m. mackermann@bcbsm.com,		Elkins, N., Hamilton, R. and m. mackermann@bcbsm.com,
	"IPv6 Performance and Diagnostic Metrics (PDM) Destination		"IPv6 Performance and Diagnostic Metrics (PDM) Destination
	Option", Internet-Draft draft-ietf-ippm-6man-pdm-		Option", Internet-Draft draft-ietf-ippm-6man-pdm-
	option-10, May 2017.		option-13, June 2017.
	[I-D.ietf-ippm-ioam-data]		[I-D.ietf-ippm-ioam-data]
	Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,		Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
	Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,		Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
	P., Chang, R. and d. daniel.bernier@bell.ca, "Data Fields		P., Chang, R., daniel.bernier@bell.ca, d. and J. Lemon,
	for In-situ OAM", Internet-Draft draft-ietf-ippm-ioam-		"Data Fields for In-situ OAM", Internet-Draft draft-ietf-
	data-01, October 2017.		ippm-ioam-data-02, March 2018.
	[I-D.ietf-quic-transport]		[I-D.ietf-quic-transport]
	Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed		Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
	and Secure Transport", Internet-Draft draft-ietf-quic-		and Secure Transport", Internet-Draft draft-ietf-quic-
	transport-03, May 2017.		transport-03, May 2017.
	[I-D.ietf-tcpm-accurate-ecn]		[I-D.ietf-tcpm-accurate-ecn]
	Briscoe, B., Kuehlewind, M. and R. Scheffenegger, "More		Briscoe, B., Kuehlewind, M. and R. Scheffenegger, "More
	Accurate ECN Feedback in TCP", Internet-Draft draft-ietf-		Accurate ECN Feedback in TCP", Internet-Draft draft-ietf-
	tcpm-accurate-ecn-00, December 2015.		tcpm-accurate-ecn-06, March 2018.
	[I-D.ietf-tsvwg-l4s-arch]		[I-D.ietf-tsvwg-l4s-arch]
	Briscoe, B., Schepper, K. and M. Bagnulo, "Low Latency,		Briscoe, B., Schepper, K. and M. Bagnulo, "Low Latency,
	Low Loss, Scalable Throughput (L4S) Internet Service:		Low Loss, Scalable Throughput (L4S) Internet Service:
	Architecture", Internet-Draft draft-ietf-tsvwg-l4s-		Architecture", Internet-Draft draft-ietf-tsvwg-l4s-
	arch-00, May 2017.		arch-01, October 2017.
	[I-D.mm-wg-effect-encrypt]		[I-D.mm-wg-effect-encrypt]
	Moriarty, K. and A. Morton, "Effect of Pervasive		Moriarty, K. and A. Morton, "Effects of Pervasive
	Encryption on Operators", Internet-Draft draft-mm-wg-		Encryption on Operators", Internet-Draft draft-mm-wg-
	effect-encrypt-11, April 2017.		effect-encrypt-24, March 2018.
			[I-D.thomson-quic-grease]
			Thomson, M., "More Apparent Randomization for QUIC",
			Internet-Draft draft-thomson-quic-grease-00, December
			2017.
	[I-D.trammell-plus-abstract-mech]		[I-D.trammell-plus-abstract-mech]
	Trammell, B., "Abstract Mechanisms for a Cooperative Path		Trammell, B., "Abstract Mechanisms for a Cooperative Path
	Layer under Endpoint Control", Internet-Draft draft-		Layer under Endpoint Control", Internet-Draft draft-
	trammell-plus-abstract-mech-00, September 2016.		trammell-plus-abstract-mech-00, September 2016.
	[I-D.trammell-plus-statefulness]		[I-D.trammell-plus-statefulness]
	Kuehlewind, M., Trammell, B. and J. Hildebrand,		Kuehlewind, M., Trammell, B. and J. Hildebrand,
	"Transport-Independent Path Layer State Management",		"Transport-Independent Path Layer State Management",
	Internet-Draft draft-trammell-plus-statefulness-02,		Internet-Draft draft-trammell-plus-statefulness-02,
	skipping to change at page 29, line 45 ¶		skipping to change at page 31, line 37 ¶
	Experimental Design, Implementation, and Policy		Experimental Design, Implementation, and Policy
	Considerations", RFC 1273, DOI 10.17487/RFC1273, November		Considerations", RFC 1273, DOI 10.17487/RFC1273, November
	1991, <https://www.rfc-editor.org/info/rfc1273>.		1991, <https://www.rfc-editor.org/info/rfc1273>.
	[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black,		[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black,
	"Definition of the Differentiated Services Field (DS		"Definition of the Differentiated Services Field (DS
	Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI		Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI
	10.17487/RFC2474, December 1998, <http://www.rfc-		10.17487/RFC2474, December 1998, <http://www.rfc-
	editor.org/info/rfc2474>.		editor.org/info/rfc2474>.
			[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
			2914, DOI 10.17487/RFC2914, September 2000, <https://www
			.rfc-editor.org/info/rfc2914>.
	[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z.		[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z.
	Shelby, "Performance Enhancing Proxies Intended to		Shelby, "Performance Enhancing Proxies Intended to
	Mitigate Link-Related Degradations", RFC 3135, DOI		Mitigate Link-Related Degradations", RFC 3135, DOI
	10.17487/RFC3135, June 2001, <http://www.rfc-editor.org/		10.17487/RFC3135, June 2001, <http://www.rfc-editor.org/
	info/rfc3135>.		info/rfc3135>.
	[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of		[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of
	Explicit Congestion Notification (ECN) to IP", RFC 3168,		Explicit Congestion Notification (ECN) to IP", RFC 3168,
	DOI 10.17487/RFC3168, September 2001, <http://www.rfc-		DOI 10.17487/RFC3168, September 2001, <http://www.rfc-
	editor.org/info/rfc3168>.		editor.org/info/rfc3168>.
	[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and		[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
	Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,		Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
	<http://www.rfc-editor.org/info/rfc3234>.		<http://www.rfc-editor.org/info/rfc3234>.
			[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
			Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI
			10.17487/RFC3393, November 2002, <https://www.rfc-
			editor.org/info/rfc3393>.
	[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M.		[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M.
	Sooriyabandara, "TCP Performance Implications of Network		Sooriyabandara, "TCP Performance Implications of Network
	Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449,		Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449,
	December 2002, <http://www.rfc-editor.org/info/rfc3449>.		December 2002, <http://www.rfc-editor.org/info/rfc3449>.
	[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V.		[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V.
	Jacobson, "RTP: A Transport Protocol for Real-Time		Jacobson, "RTP: A Transport Protocol for Real-Time
	Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,		Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
	July 2003, <http://www.rfc-editor.org/info/rfc3550>.		July 2003, <http://www.rfc-editor.org/info/rfc3550>.
	[RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D.,
	Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J. and L.
	Wood, "Advice for Internet Subnetwork Designers", BCP 89,
	RFC 3819, DOI 10.17487/RFC3819, July 2004, <http://www
	.rfc-editor.org/info/rfc3819>.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,		Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
	December 2005, <http://www.rfc-editor.org/info/rfc4301>.		December 2005, <http://www.rfc-editor.org/info/rfc4301>.
	[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI		[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI
	10.17487/RFC4302, December 2005, <http://www.rfc-		10.17487/RFC4302, December 2005, <http://www.rfc-
	editor.org/info/rfc4302>.		editor.org/info/rfc4302>.
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
	4303, DOI 10.17487/RFC4303, December 2005, <http://www		4303, DOI 10.17487/RFC4303, December 2005, <http://www
	skipping to change at page 31, line 5 ¶		skipping to change at page 32, line 53 ¶
	[RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A. and R.		[RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A. and R.
	Whitner, "Improved Packet Reordering Metrics", RFC 5236,		Whitner, "Improved Packet Reordering Metrics", RFC 5236,
	DOI 10.17487/RFC5236, June 2008, <http://www.rfc-		DOI 10.17487/RFC5236, June 2008, <http://www.rfc-
	editor.org/info/rfc5236>.		editor.org/info/rfc5236>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/		(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
	RFC5246, August 2008, <http://www.rfc-editor.org/info/		RFC5246, August 2008, <http://www.rfc-editor.org/info/
	rfc5246>.		rfc5246>.
			[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
			Applicability Statement", RFC 5481, DOI 10.17487/RFC5481,
			March 2009, <https://www.rfc-editor.org/info/rfc5481>.
	[RFC5559] Eardley, P., Ed., "Pre-Congestion Notification (PCN)		[RFC5559] Eardley, P., Ed., "Pre-Congestion Notification (PCN)
	Architecture", RFC 5559, DOI 10.17487/RFC5559, June 2009,		Architecture", RFC 5559, DOI 10.17487/RFC5559, June 2009,
	<http://www.rfc-editor.org/info/rfc5559>.		<http://www.rfc-editor.org/info/rfc5559>.
	[RFC5925] Touch, J., Mankin, A. and R. Bonica, "The TCP		[RFC5925] Touch, J., Mankin, A. and R. Bonica, "The TCP
	Authentication Option", RFC 5925, DOI 10.17487/RFC5925,		Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
	June 2010, <http://www.rfc-editor.org/info/rfc5925>.		June 2010, <http://www.rfc-editor.org/info/rfc5925>.
	[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P. and P.		[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P. and P.
	Roberts, "Issues with IP Address Sharing", RFC 6269, DOI		Roberts, "Issues with IP Address Sharing", RFC 6269, DOI
	skipping to change at page 31, line 54 ¶		skipping to change at page 33, line 54 ¶
	197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <http://		197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <http://
	www.rfc-editor.org/info/rfc7567>.		www.rfc-editor.org/info/rfc7567>.
	[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,		[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
	Trammell, B., Huitema, C. and D. Borkmann,		Trammell, B., Huitema, C. and D. Borkmann,
	"Confidentiality in the Face of Pervasive Surveillance: A		"Confidentiality in the Face of Pervasive Surveillance: A
	Threat Model and Problem Statement", RFC 7624, DOI		Threat Model and Problem Statement", RFC 7624, DOI
	10.17487/RFC7624, August 2015, <http://www.rfc-editor.org/		10.17487/RFC7624, August 2015, <http://www.rfc-editor.org/
	info/rfc7624>.		info/rfc7624>.
	[RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx)
	Concepts, Abstract Mechanism, and Requirements", RFC 7713,
	DOI 10.17487/RFC7713, December 2015, <http://www.rfc-
	editor.org/info/rfc7713>.
	[RFC7872] Gont, F., Linkova, J., Chown, T. and W. Liu, "Observations		[RFC7872] Gont, F., Linkova, J., Chown, T. and W. Liu, "Observations
	on the Dropping of Packets with IPv6 Extension Headers in		on the Dropping of Packets with IPv6 Extension Headers in
	the Real World", RFC 7872, DOI 10.17487/RFC7872, June		the Real World", RFC 7872, DOI 10.17487/RFC7872, June
	2016, <https://www.rfc-editor.org/info/rfc7872>.		2016, <https://www.rfc-editor.org/info/rfc7872>.
	[RFC7928] Kuhn, N., Ed., Natarajan, P., Ed., Khademi, N.Ed., and D.		[RFC7928] Kuhn, N., Ed., Natarajan, P., Ed., Khademi, N.Ed., and D.
	Ros, "Characterization Guidelines for Active Queue		Ros, "Characterization Guidelines for Active Queue
	Management (AQM)", RFC 7928, DOI 10.17487/RFC7928, July		Management (AQM)", RFC 7928, DOI 10.17487/RFC7928, July
	2016, <http://www.rfc-editor.org/info/rfc7928>.		2016, <http://www.rfc-editor.org/info/rfc7928>.
	skipping to change at page 33, line 11 ¶		skipping to change at page 35, line 5 ¶
	Comments from the community are welcome on the text and		Comments from the community are welcome on the text and
	recommendations.		recommendations.
	-05 Corrections received and helpful inputs from Mohamed Boucadair.		-05 Corrections received and helpful inputs from Mohamed Boucadair.
	-06 Updated following comments from Stephen Farrell, and feedback via		-06 Updated following comments from Stephen Farrell, and feedback via
	email. Added a draft conclusion section to sketch some strawman		email. Added a draft conclusion section to sketch some strawman
	scenarios that could emerge.		scenarios that could emerge.
			-07 Updated following comments from Al Morton, Chris Seal, and other
			feedback via email.
	Authors' Addresses		Authors' Addresses
	Godred Fairhurst		Godred Fairhurst
	University of Aberdeen		University of Aberdeen
	Department of Engineering		Department of Engineering
	Fraser Noble Building		Fraser Noble Building
	Aberdeen, AB24 3UE		Aberdeen, AB24 3UE
	Scotland		Scotland
	Email: gorry@erg.abdn.ac.uk		Email: gorry@erg.abdn.ac.uk
End of changes. 102 change blocks.
	488 lines changed or deleted		532 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/