draft-ietf-taps-interface-14.txt   draft-ietf-taps-interface-15.txt 
TAPS Working Group B. Trammell, Ed. TAPS Working Group B. Trammell, Ed.
Internet-Draft Google Switzerland GmbH Internet-Draft Google Switzerland GmbH
Intended status: Standards Track M. Welzl, Ed. Intended status: Standards Track M. Welzl, Ed.
Expires: 7 July 2022 University of Oslo Expires: 8 September 2022 University of Oslo
T. Enghardt T. Enghardt
Netflix Netflix
G. Fairhurst G. Fairhurst
University of Aberdeen University of Aberdeen
M. Kuehlewind M. Kuehlewind
Ericsson Ericsson
C. Perkins C. Perkins
University of Glasgow University of Glasgow
P. Tiesel P. Tiesel
SAP SE SAP SE
C.A. Wood
Cloudflare
T. Pauly T. Pauly
Apple Inc. Apple Inc.
K. Rose 7 March 2022
Akamai Technologies, Inc.
3 January 2022
An Abstract Application Layer Interface to Transport Services An Abstract Application Layer Interface to Transport Services
draft-ietf-taps-interface-14 draft-ietf-taps-interface-15
Abstract Abstract
This document describes an abstract application programming This document describes an abstract application programming
interface, API, to the transport layer that enables the selection of interface, API, to the transport layer that enables the selection of
transport protocols and network paths dynamically at runtime. This transport protocols and network paths dynamically at runtime. This
API enables faster deployment of new protocols and protocol features API enables faster deployment of new protocols and protocol features
without requiring changes to the applications. The specified API without requiring changes to the applications. The specified API
follows the Transport Services architecture by providing follows the Transport Services architecture by providing
asynchronous, atomic transmission of messages. It is intended to asynchronous, atomic transmission of messages. It is intended to
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 7 July 2022. This Internet-Draft will expire on 8 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://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
skipping to change at page 3, line 23 skipping to change at page 3, line 23
6.2.13. Use Temporary Local Address . . . . . . . . . . . . . 31 6.2.13. Use Temporary Local Address . . . . . . . . . . . . . 31
6.2.14. Multipath Transport . . . . . . . . . . . . . . . . . 32 6.2.14. Multipath Transport . . . . . . . . . . . . . . . . . 32
6.2.15. Advertisement of Alternative Addresses . . . . . . . 33 6.2.15. Advertisement of Alternative Addresses . . . . . . . 33
6.2.16. Direction of communication . . . . . . . . . . . . . 33 6.2.16. Direction of communication . . . . . . . . . . . . . 33
6.2.17. Notification of ICMP soft error message arrival . . . 34 6.2.17. Notification of ICMP soft error message arrival . . . 34
6.2.18. Initiating side is not the first to write . . . . . . 34 6.2.18. Initiating side is not the first to write . . . . . . 34
6.3. Specifying Security Parameters and Callbacks . . . . . . 35 6.3. Specifying Security Parameters and Callbacks . . . . . . 35
6.3.1. Specifying Security Parameters on a Pre-Connection . 35 6.3.1. Specifying Security Parameters on a Pre-Connection . 35
6.3.2. Connection Establishment Callbacks . . . . . . . . . 37 6.3.2. Connection Establishment Callbacks . . . . . . . . . 37
7. Establishing Connections . . . . . . . . . . . . . . . . . . 37 7. Establishing Connections . . . . . . . . . . . . . . . . . . 37
7.1. Active Open: Initiate . . . . . . . . . . . . . . . . . . 37 7.1. Active Open: Initiate . . . . . . . . . . . . . . . . . . 38
7.2. Passive Open: Listen . . . . . . . . . . . . . . . . . . 39 7.2. Passive Open: Listen . . . . . . . . . . . . . . . . . . 39
7.3. Peer-to-Peer Establishment: Rendezvous . . . . . . . . . 40 7.3. Peer-to-Peer Establishment: Rendezvous . . . . . . . . . 40
7.4. Connection Groups . . . . . . . . . . . . . . . . . . . . 42 7.4. Connection Groups . . . . . . . . . . . . . . . . . . . . 42
7.5. Adding and Removing Endpoints on a Connection . . . . . . 43 7.5. Adding and Removing Endpoints on a Connection . . . . . . 44
8. Managing Connections . . . . . . . . . . . . . . . . . . . . 44 8. Managing Connections . . . . . . . . . . . . . . . . . . . . 44
8.1. Generic Connection Properties . . . . . . . . . . . . . . 46 8.1. Generic Connection Properties . . . . . . . . . . . . . . 46
8.1.1. Required Minimum Corruption Protection Coverage for 8.1.1. Required Minimum Corruption Protection Coverage for
Receiving . . . . . . . . . . . . . . . . . . . . . . 46 Receiving . . . . . . . . . . . . . . . . . . . . . . 46
8.1.2. Connection Priority . . . . . . . . . . . . . . . . . 46 8.1.2. Connection Priority . . . . . . . . . . . . . . . . . 47
8.1.3. Timeout for Aborting Connection . . . . . . . . . . . 47 8.1.3. Timeout for Aborting Connection . . . . . . . . . . . 47
8.1.4. Timeout for keep alive packets . . . . . . . . . . . 47 8.1.4. Timeout for keep alive packets . . . . . . . . . . . 47
8.1.5. Connection Group Transmission Scheduler . . . . . . . 47 8.1.5. Connection Group Transmission Scheduler . . . . . . . 48
8.1.6. Capacity Profile . . . . . . . . . . . . . . . . . . 48 8.1.6. Capacity Profile . . . . . . . . . . . . . . . . . . 48
8.1.7. Policy for using Multipath Transports . . . . . . . . 49 8.1.7. Policy for using Multipath Transports . . . . . . . . 50
8.1.8. Bounds on Send or Receive Rate . . . . . . . . . . . 50 8.1.8. Bounds on Send or Receive Rate . . . . . . . . . . . 51
8.1.9. Group Connection Limit . . . . . . . . . . . . . . . 51 8.1.9. Group Connection Limit . . . . . . . . . . . . . . . 51
8.1.10. Isolate Session . . . . . . . . . . . . . . . . . . . 51 8.1.10. Isolate Session . . . . . . . . . . . . . . . . . . . 51
8.1.11. Read-only Connection Properties . . . . . . . . . . . 51 8.1.11. Read-only Connection Properties . . . . . . . . . . . 52
8.2. TCP-specific Properties: User Timeout Option (UTO) . . . 52 8.2. TCP-specific Properties: User Timeout Option (UTO) . . . 53
8.2.1. Advertised User Timeout . . . . . . . . . . . . . . . 53 8.2.1. Advertised User Timeout . . . . . . . . . . . . . . . 53
8.2.2. User Timeout Enabled . . . . . . . . . . . . . . . . 53 8.2.2. User Timeout Enabled . . . . . . . . . . . . . . . . 53
8.2.3. Timeout Changeable . . . . . . . . . . . . . . . . . 53 8.2.3. Timeout Changeable . . . . . . . . . . . . . . . . . 54
8.3. Connection Lifecycle Events . . . . . . . . . . . . . . . 54 8.3. Connection Lifecycle Events . . . . . . . . . . . . . . . 54
8.3.1. Soft Errors . . . . . . . . . . . . . . . . . . . . . 54 8.3.1. Soft Errors . . . . . . . . . . . . . . . . . . . . . 54
8.3.2. Path change . . . . . . . . . . . . . . . . . . . . . 54 8.3.2. Path change . . . . . . . . . . . . . . . . . . . . . 54
9. Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . 54 9. Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . 54
9.1. Messages and Framers . . . . . . . . . . . . . . . . . . 54 9.1. Messages and Framers . . . . . . . . . . . . . . . . . . 55
9.1.1. Message Contexts . . . . . . . . . . . . . . . . . . 55 9.1.1. Message Contexts . . . . . . . . . . . . . . . . . . 55
9.1.2. Message Framers . . . . . . . . . . . . . . . . . . . 55 9.1.2. Message Framers . . . . . . . . . . . . . . . . . . . 55
9.1.3. Message Properties . . . . . . . . . . . . . . . . . 57 9.1.3. Message Properties . . . . . . . . . . . . . . . . . 58
9.2. Sending Data . . . . . . . . . . . . . . . . . . . . . . 63 9.2. Sending Data . . . . . . . . . . . . . . . . . . . . . . 64
9.2.1. Basic Sending . . . . . . . . . . . . . . . . . . . . 63 9.2.1. Basic Sending . . . . . . . . . . . . . . . . . . . . 64
9.2.2. Send Events . . . . . . . . . . . . . . . . . . . . . 64 9.2.2. Send Events . . . . . . . . . . . . . . . . . . . . . 65
9.2.3. Partial Sends . . . . . . . . . . . . . . . . . . . . 65 9.2.3. Partial Sends . . . . . . . . . . . . . . . . . . . . 66
9.2.4. Batching Sends . . . . . . . . . . . . . . . . . . . 66 9.2.4. Batching Sends . . . . . . . . . . . . . . . . . . . 66
9.2.5. Send on Active Open: InitiateWithSend . . . . . . . . 66 9.2.5. Send on Active Open: InitiateWithSend . . . . . . . . 67
9.2.6. Priority and the Transport Services API . . . . . . . 67 9.2.6. Priority and the Transport Services API . . . . . . . 67
9.3. Receiving Data . . . . . . . . . . . . . . . . . . . . . 67 9.3. Receiving Data . . . . . . . . . . . . . . . . . . . . . 68
9.3.1. Enqueuing Receives . . . . . . . . . . . . . . . . . 67 9.3.1. Enqueuing Receives . . . . . . . . . . . . . . . . . 68
9.3.2. Receive Events . . . . . . . . . . . . . . . . . . . 68 9.3.2. Receive Events . . . . . . . . . . . . . . . . . . . 69
9.3.3. Receive Message Properties . . . . . . . . . . . . . 71 9.3.3. Receive Message Properties . . . . . . . . . . . . . 71
10. Connection Termination . . . . . . . . . . . . . . . . . . . 72 10. Connection Termination . . . . . . . . . . . . . . . . . . . 73
11. Connection State and Ordering of Operations and Events . . . 73 11. Connection State and Ordering of Operations and Events . . . 74
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76
13. Privacy and Security Considerations . . . . . . . . . . . . . 75 13. Privacy and Security Considerations . . . . . . . . . . . . . 76
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 77 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 78
15.1. Normative References . . . . . . . . . . . . . . . . . . 77 15.1. Normative References . . . . . . . . . . . . . . . . . . 78
15.2. Informative References . . . . . . . . . . . . . . . . . 78 15.2. Informative References . . . . . . . . . . . . . . . . . 79
Appendix A. Implementation Mapping . . . . . . . . . . . . . . . 81 Appendix A. Implementation Mapping . . . . . . . . . . . . . . . 83
A.1. Types . . . . . . . . . . . . . . . . . . . . . . . . . . 82 A.1. Types . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.2. Events and Errors . . . . . . . . . . . . . . . . . . . . 82 A.2. Events and Errors . . . . . . . . . . . . . . . . . . . . 84
A.3. Time Duration . . . . . . . . . . . . . . . . . . . . . . 82 A.3. Time Duration . . . . . . . . . . . . . . . . . . . . . . 84
Appendix B. Convenience Functions . . . . . . . . . . . . . . . 83 Appendix B. Convenience Functions . . . . . . . . . . . . . . . 84
B.1. Adding Preference Properties . . . . . . . . . . . . . . 83 B.1. Adding Preference Properties . . . . . . . . . . . . . . 84
B.2. Transport Property Profiles . . . . . . . . . . . . . . . 83 B.2. Transport Property Profiles . . . . . . . . . . . . . . . 84
B.2.1. reliable-inorder-stream . . . . . . . . . . . . . . . 83 B.2.1. reliable-inorder-stream . . . . . . . . . . . . . . . 84
B.2.2. reliable-message . . . . . . . . . . . . . . . . . . 84 B.2.2. reliable-message . . . . . . . . . . . . . . . . . . 85
B.2.3. unreliable-datagram . . . . . . . . . . . . . . . . . 84 B.2.3. unreliable-datagram . . . . . . . . . . . . . . . . . 85
Appendix C. Relationship to the Minimal Set of Transport Services Appendix C. Relationship to the Minimal Set of Transport Services
for End Systems . . . . . . . . . . . . . . . . . . . . . 85 for End Systems . . . . . . . . . . . . . . . . . . . . . 86
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 89
1. Introduction 1. Introduction
This document specifies an abstract application programming interface This document specifies an abstract application programming interface
(API) that specifies the interface component of the high-level (API) that specifies the interface component of the high-level
Transport Services architecture defined in [I-D.ietf-taps-arch]. A Transport Services architecture defined in [I-D.ietf-taps-arch]. A
Transport Services system supports asynchronous, atomic transmission Transport Services system supports asynchronous, atomic transmission
of messages over transport protocols and network paths dynamically of messages over transport protocols and network paths dynamically
selected at runtime, in environments where an endpoint selects from selected at runtime, in environments where an endpoint selects from
multiple interfaces and potential transport protocols. multiple interfaces and potential transport protocols.
skipping to change at page 24, line 15 skipping to change at page 24, line 15
The protocol(s) and path(s) selected as candidates during The protocol(s) and path(s) selected as candidates during
establishment are determined and configured using these properties. establishment are determined and configured using these properties.
Since there could be paths over which some transport protocols are Since there could be paths over which some transport protocols are
unable to operate, or remote endpoints that support only specific unable to operate, or remote endpoints that support only specific
network addresses or transports, transport protocol selection is network addresses or transports, transport protocol selection is
necessarily tied to path selection. This may involve choosing necessarily tied to path selection. This may involve choosing
between multiple local interfaces that are connected to different between multiple local interfaces that are connected to different
access networks. access networks.
When additional information (such as Provisioning Domain (PvD) When additional information (such as Provisioning Domain (PvD)
information [RFC7556]) is available about the networks over which an information Path information can include network segment PMTU, set of
endpoint can operate, this can inform the selection between alternate supported DSCPs, expected usage, cost, etc. The usage of this
network paths. information by the Transport Services System is generally independent
Path information can include network segment PMTU, set of supported of the specific mechanism/protocol used to receive the information
DSCPs, expected usage, cost, etc. The usage of this information by (e.g. zero-conf, DHCP, or IPv6 RA).[RFC7556]) is available about the
the Transport Services System is generally independent of the networks over which an endpoint can operate, this can inform the
specific mechanism/protocol used to receive the information (e.g. selection between alternate network paths.
zero-conf, DHCP, or IPv6 RA).
Most Selection Properties are represented as Preferences, which can Most Selection Properties are represented as Preferences, which can
take one of five values: take one of five values:
+============+========================================+ +============+========================================+
| Preference | Effect | | Preference | Effect |
+============+========================================+ +============+========================================+
| Require | Select only protocols/paths providing | | Require | Select only protocols/paths providing |
| | the property, fail otherwise | | | the property, fail otherwise |
+------------+----------------------------------------+ +------------+----------------------------------------+
skipping to change at page 32, line 7 skipping to change at page 32, line 7
Name: useTemporaryLocalAddress Name: useTemporaryLocalAddress
Type: Preference Type: Preference
Default: Avoid for Listeners and Rendezvous Connections. Prefer for Default: Avoid for Listeners and Rendezvous Connections. Prefer for
other Connections. other Connections.
This property allows the application to express a preference for the This property allows the application to express a preference for the
use of temporary local addresses, sometimes called "privacy" use of temporary local addresses, sometimes called "privacy"
addresses [RFC4941]. Temporary addresses are generally used to addresses [RFC8981]. Temporary addresses are generally used to
prevent linking connections over time when a stable address, prevent linking connections over time when a stable address,
sometimes called "permanent" address, is not needed. There are some sometimes called "permanent" address, is not needed. There are some
caveats to note when specifying this property. First, if an caveats to note when specifying this property. First, if an
application Requires the use of temporary addresses, the resulting application Requires the use of temporary addresses, the resulting
Connection cannot use IPv4, because temporary addresses do not exist Connection cannot use IPv4, because temporary addresses do not exist
in IPv4. Second, temporary local addresses might involve trading off in IPv4. Second, temporary local addresses might involve trading off
privacy for performance. For instance, temporary addresses can privacy for performance. For instance, temporary addresses can
interfere with resumption mechanisms that some protocols rely on to interfere with resumption mechanisms that some protocols rely on to
reduce initial latency. reduce initial latency.
skipping to change at page 35, line 8 skipping to change at page 35, line 8
Name: activeReadBeforeSend Name: activeReadBeforeSend
Type: Preference Type: Preference
Default: Ignore Default: Ignore
The most common client-server communication pattern involves the The most common client-server communication pattern involves the
client actively opening a connection, then sending data to the client actively opening a connection, then sending data to the
server. The server listens (passive open), reads, and then answers. server. The server listens (passive open), reads, and then answers.
This property specifies whether an application wants to diverge from This property specifies whether an application wants to diverge from
this pattern -- either by actively opening with Initiate(), this pattern - either by actively opening with Initiate(),
immediately followed by reading, or passively opening with Listen(), immediately followed by reading, or passively opening with Listen(),
immediately followed by writing. This property is ignored when immediately followed by writing. This property is ignored when
establishing connections using Rendezvous(). Requiring this property establishing connections using Rendezvous(). Requiring this property
limits the choice of mappings to underlying protocols, which can limits the choice of mappings to underlying protocols, which can
reduce efficiency. For example, it prevents the Transport Services reduce efficiency. For example, it prevents the Transport Services
system from mapping Connections to SCTP streams, where the first system from mapping Connections to SCTP streams, where the first
transmitted data takes the role of an active open signal transmitted data takes the role of an active open signal
[I-D.ietf-taps-impl]. [I-D.ietf-taps-impl].
6.3. Specifying Security Parameters and Callbacks 6.3. Specifying Security Parameters and Callbacks
skipping to change at page 37, line 17 skipping to change at page 37, line 17
Security decisions, especially pertaining to trust, are not static. Security decisions, especially pertaining to trust, are not static.
Once configured, parameters may also be supplied during connection Once configured, parameters may also be supplied during connection
establishment. These are best handled as client-provided callbacks. establishment. These are best handled as client-provided callbacks.
Callbacks block the progress of the connection establishment, which Callbacks block the progress of the connection establishment, which
distinguishes them from other Events in the transport system. How distinguishes them from other Events in the transport system. How
callbacks and events are implemented is specific to each callbacks and events are implemented is specific to each
implementation. Security handshake callbacks that may be invoked implementation. Security handshake callbacks that may be invoked
during connection establishment include: during connection establishment include:
* Trust verification callback: Invoked when a Remote Endpoint's * Trust verification callback: Invoked when a Remote Endpoint's
trust must be validated before the handshake protocol can trust must be verified before the handshake protocol can continue.
continue. For example, the application could verify an X.509 certificate as
described in [RFC5280].
TrustCallback := NewCallback({ TrustCallback := NewCallback({
// Handle trust, return the result // Handle trust, return the result
}) })
SecurityParameters.SetTrustVerificationCallback(trustCallback) SecurityParameters.SetTrustVerificationCallback(trustCallback)
* Identity challenge callback: Invoked when a private key operation * Identity challenge callback: Invoked when a private key operation
is required, e.g., when local authentication is requested by a is required, e.g., when local authentication is requested by a
Remote Endpoint. Remote Endpoint.
skipping to change at page 40, line 40 skipping to change at page 40, line 49
The Rendezvous() Action listens on the Local Endpoint candidates for The Rendezvous() Action listens on the Local Endpoint candidates for
an incoming Connection from the Remote Endpoint candidates, while an incoming Connection from the Remote Endpoint candidates, while
also simultaneously trying to establish a Connection from the Local also simultaneously trying to establish a Connection from the Local
Endpoint candidates to the Remote Endpoint candidates. Endpoint candidates to the Remote Endpoint candidates.
If there are multiple Local Endpoints or Remote Endpoints configured, If there are multiple Local Endpoints or Remote Endpoints configured,
then initiating a Rendezvous() action will systematically probe the then initiating a Rendezvous() action will systematically probe the
reachability of those endpoint candidates following an approach such reachability of those endpoint candidates following an approach such
as that used in Interactive Connectivity Establishment (ICE) as that used in Interactive Connectivity Establishment (ICE)
[RFC5245]. [RFC8445].
If the endpoints are suspected to be behind a NAT, Rendezvous() can If the endpoints are suspected to be behind a NAT, Rendezvous() can
be initiated using Local Endpoints that support a method of be initiated using Local Endpoints that support a method of
discovering NAT bindings such as Session Traversal Utilities for NAT discovering NAT bindings such as Session Traversal Utilities for NAT
(STUN) [RFC8489] or Traversal Using Relays around NAT (TURN) (STUN) [RFC8489] or Traversal Using Relays around NAT (TURN)
[RFC5766]. In this case, the Local Endpoint will resolve to a [RFC8656]. In this case, the Local Endpoint will resolve to a
mixture of local and server reflexive addresses. The Resolve() mixture of local and server reflexive addresses. The Resolve()
action on the Preconnection can be used to discover these bindings: action on the Preconnection can be used to discover these bindings:
[]LocalEndpoint, []RemoteEndpoint := Preconnection.Resolve() []LocalEndpoint, []RemoteEndpoint := Preconnection.Resolve()
The Resolve() call returns lists of Local Endpoints and Remote The Resolve() call returns lists of Local Endpoints and Remote
Endpoints, that represent the concrete addresses, local and server Endpoints, that represent the concrete addresses, local and server
reflexive, on which a Rendezvous() for the Preconnection will listen reflexive, on which a Rendezvous() for the Preconnection will listen
for incoming Connections, and to which it will attempt to establish for incoming Connections, and to which it will attempt to establish
connections. connections.
Note that the set of LocalEndpoints returned by Resolve() might or Note that the set of LocalEndpoints returned by Resolve() might or
might not contain information about all possible local interfaces; it might not contain information about all possible local interfaces; it
is valid only for a Rendezvous happening at the same time as the is valid only for a Rendezvous happening at the same time as the
resolution. Care should be taken in using these values in any other resolution. Care should be taken in using these values in any other
skipping to change at page 43, line 9 skipping to change at page 43, line 21
Framers may internally maintain per-Connection state. Framers may internally maintain per-Connection state.
It is also possible to check which Connections belong to the same It is also possible to check which Connections belong to the same
Connection Group. Calling GroupedConnections() on a specific Connection Group. Calling GroupedConnections() on a specific
Connection returns a set of all Connections in the same group. Connection returns a set of all Connections in the same group.
[]Connection := Connection.GroupedConnections() []Connection := Connection.GroupedConnections()
Connections will belong to the same group if the application Connections will belong to the same group if the application
previously called Clone. Passive Connections can also be added to previously called Clone. Passive Connections can also be added to
the same group -- e.g., when a Listener receives a new Connection the same group - e.g., when a Listener receives a new Connection that
that is just a new stream of an already active multi-streaming is just a new stream of an already active multi-streaming protocol
protocol instance. instance.
If the underlying protocol supports multi-streaming, it is natural to If the underlying protocol supports multi-streaming, it is natural to
use this functionality to implement Clone. In that case, Connections use this functionality to implement Clone. In that case, Connections
in a Connection Group are multiplexed together, giving them similar in a Connection Group are multiplexed together, giving them similar
treatment not only inside endpoints, but also across the end-to-end treatment not only inside endpoints, but also across the end-to-end
Internet path. Internet path.
Note that calling Clone() can result in on-the-wire signaling, e.g., Note that calling Clone() can result in on-the-wire signaling, e.g.,
to open a new transport connection, depending on the underlying to open a new transport connection, depending on the underlying
Protocol Stack. When Clone() leads to the opening of multiple such Protocol Stack. When Clone() leads to the opening of multiple such
skipping to change at page 52, line 4 skipping to change at page 52, line 20
8.1.11. Read-only Connection Properties 8.1.11. Read-only Connection Properties
The following generic Connection Properties are read-only, i.e. they The following generic Connection Properties are read-only, i.e. they
cannot be changed by an application. cannot be changed by an application.
8.1.11.1. Maximum Message Size Concurrent with Connection Establishment 8.1.11.1. Maximum Message Size Concurrent with Connection Establishment
Name: zeroRttMsgMaxLen Name: zeroRttMsgMaxLen
Type: Integer Type: Integer
This property represents the maximum Message size that can be sent This property represents the maximum Message size that can be sent
before or during Connection establishment, see also Section 9.1.3.4. before or during Connection establishment, see also Section 9.1.3.4.
It is given in Bytes. It is specified as the number of bytes.
8.1.11.2. Maximum Message Size Before Fragmentation or Segmentation 8.1.11.2. Maximum Message Size Before Fragmentation or Segmentation
Name: singularTransmissionMsgMaxLen Name: singularTransmissionMsgMaxLen
Type: Integer Type: Integer
This property, if applicable, represents the maximum Message size This property, if applicable, represents the maximum Message size
that can be sent without incurring network-layer fragmentation at the that can be sent without incurring network-layer fragmentation at the
sender. It exposes a value to the application based on the Maximum sender. It is specified as the number of bytes. It exposes a value
Packet Size (MPS) as described in Datagram PLPMTUD [RFC8899]. This to the application based on the Maximum Packet Size (MPS) as
can allow a sending stack to avoid unwanted fragmentation at the described in Datagram PLPMTUD [RFC8899]. This can allow a sending
network-layer or segmentation by the transport layer. stack to avoid unwanted fragmentation at the network-layer or
segmentation by the transport layer.
8.1.11.3. Maximum Message Size on Send 8.1.11.3. Maximum Message Size on Send
Name: sendMsgMaxLen Name: sendMsgMaxLen
Type: Integer Type: Integer
This property represents the maximum Message size that an application This property represents the maximum Message size that an application
can send. can send. It is specified as the nummber of bytes.
8.1.11.4. Maximum Message Size on Receive 8.1.11.4. Maximum Message Size on Receive
Name: recvMsgMaxLen Name: recvMsgMaxLen
Type: Integer Type: Integer
This numeric property represents the maximum Message size that an This numeric property represents the maximum Message size that an
application can receive. application can receive. It specified as the number of bytes.
8.2. TCP-specific Properties: User Timeout Option (UTO) 8.2. TCP-specific Properties: User Timeout Option (UTO)
These properties specify configurations for the User Timeout Option These properties specify configurations for the User Timeout Option
(UTO), in the case that TCP becomes the chosen transport protocol. (UTO), in the case that TCP becomes the chosen transport protocol.
Implementation is optional and useful only if TCP is implemented in Implementation is optional and useful only if TCP is implemented in
the Transport Services system. the Transport Services system.
These TCP-specific properties are included here because the feature These TCP-specific properties are included here because the feature
Suggest timeout to the peer is part of the minimal set of transport Suggest timeout to the peer is part of the minimal set of transport
skipping to change at page 55, line 15 skipping to change at page 55, line 24
9.1.1. Message Contexts 9.1.1. Message Contexts
Using the MessageContext object, the application can set and retrieve Using the MessageContext object, the application can set and retrieve
meta-data of the message, including Message Properties (see meta-data of the message, including Message Properties (see
Section 9.1.3) and framing meta-data (see Section 9.1.2.2). Section 9.1.3) and framing meta-data (see Section 9.1.2.2).
Therefore, a MessageContext object can be passed to the Send action Therefore, a MessageContext object can be passed to the Send action
and is returned by each Send and Receive related event. and is returned by each Send and Receive related event.
Message Properties can be set and queried using the Message Context: Message Properties can be set and queried using the Message Context:
MessageContext.add(scope?, parameter, value) MessageContext.add(property, value)
PropertyValue := MessageContext.get(scope?, property) PropertyValue := MessageContext.get(property)
To get or set Message Properties, the optional scope parameter is These Message Properties may be generic properties or Protocol
left empty. To get or set meta-data for a Framer, the application Specific Properties.
has to pass a reference to this Framer as the scope parameter.
For MessageContexts returned by send Events (see Section 9.2.2) and For MessageContexts returned by send Events (see Section 9.2.2) and
receive Events (see Section 9.3.2), the application can query receive Events (see Section 9.3.2), the application can query
information about the Local and Remote Endpoint: information about the Local and Remote Endpoint:
RemoteEndpoint := MessageContext.GetRemoteEndpoint() RemoteEndpoint := MessageContext.GetRemoteEndpoint()
LocalEndpoint := MessageContext.GetLocalEndpoint() LocalEndpoint := MessageContext.GetLocalEndpoint()
9.1.2. Message Framers 9.1.2. Message Framers
skipping to change at page 57, line 17 skipping to change at page 57, line 25
framer := NewHTTPMessageFramer() framer := NewHTTPMessageFramer()
Preconnection.AddFramer(framer) Preconnection.AddFramer(framer)
Since Message Framers pass from Preconnection to Listener or Since Message Framers pass from Preconnection to Listener or
Connection, addition of Framers must happen before any operation that Connection, addition of Framers must happen before any operation that
may result in the creation of a Connection. may result in the creation of a Connection.
9.1.2.2. Framing Meta-Data 9.1.2.2. Framing Meta-Data
When sending Messages, applications can add Framer-specific key/value When sending Messages, applications can add Framer-specific
pairs to a MessageContext (Section 9.1.1). This mechanism can be properties to a MessageContext (Section 9.1.1). In order to set
used, for example, to set the type of a Message for a TLV format. these properties, the add and get actions on the MessageContext. To
The namespace of values is custom for each unique Message Framer. avoid naming conflicts, the property names SHOULD be prefixed with a
namespace referencing the framer implementation or the protocol it
implements as described in Section 4.1.
This mechanism can be used, for example, to set the type of a Message
for a TLV format. The namespace of values is custom for each unique
Message Framer.
messageContext := NewMessageContext() messageContext := NewMessageContext()
messageContext.add(framer, key, value) messageContext.add(framer, key, value)
Connection.Send(messageData, messageContext) Connection.Send(messageData, messageContext)
When an application receives a MessageContext in a Receive event, it When an application receives a MessageContext in a Receive event, it
can also look to see if a value was set by a specific Message Framer. can also look to see if a value was set by a specific Message Framer.
messageContext.get(framer, key) -> value messageContext.get(framer, key) -> value
skipping to change at page 58, line 26 skipping to change at page 58, line 40
If an application wants to override Message Properties for a specific If an application wants to override Message Properties for a specific
message, it can acquire an empty MessageContext Object and add all message, it can acquire an empty MessageContext Object and add all
desired Message Properties to that Object. It can then reuse the desired Message Properties to that Object. It can then reuse the
same messageContext Object for sending multiple Messages with the same messageContext Object for sending multiple Messages with the
same properties. same properties.
Properties can be added to a MessageContext object only before the Properties can be added to a MessageContext object only before the
context is used for sending. Once a MessageContext has been used context is used for sending. Once a MessageContext has been used
with a Send call, further modifications to the MessageContext object with a Send call, further modifications to the MessageContext object
do not have any effect on this Send call. do not have any effect on this Send call. Message Properties that
are not added to a MessageContext object before using the context for
sending will either take a specific default value or be configured
based on Selection or Connection Properties of the Connection that is
associated with the Send call. This initialization behavior is
defined per Message Property below.
The Message Properties could be inconsistent with the properties of The Message Properties could be inconsistent with the properties of
the Protocol Stacks underlying the Connection on which a given the Protocol Stacks underlying the Connection on which a given
Message is sent. For example, a Protocol Stack must be able to Message is sent. For example, a Protocol Stack must be able to
provide ordering if the msgOrdered property of a Message is enabled. provide ordering if the msgOrdered property of a Message is enabled.
Sending a Message with Message Properties inconsistent with the Sending a Message with Message Properties inconsistent with the
Selection Properties of the Connection yields an error. Selection Properties of the Connection yields an error.
If a Message Property contradicts a Connection Property, and if this If a Message Property contradicts a Connection Property, and if this
per-Message behavior can be supported, it overrides the Connection per-Message behavior can be supported, it overrides the Connection
skipping to change at page 59, line 4 skipping to change at page 59, line 23
Connections that were established enabling the Selection Property Connections that were established enabling the Selection Property
Configure Per-Message Reliability. Configure Per-Message Reliability.
The following Message Properties are supported: The following Message Properties are supported:
9.1.3.1. Lifetime 9.1.3.1. Lifetime
Name: msgLifetime Name: msgLifetime
Type: Numeric Type: Numeric
Default: infinite Default: infinite
The Lifetime specifies how long a particular Message can wait to be The Lifetime specifies how long a particular Message can wait to be
sent to the Remote Endpoint before it is irrelevant and no longer sent to the Remote Endpoint before it is irrelevant and no longer
needs to be (re-)transmitted. This is a hint to the Transport needs to be (re-)transmitted. This is a hint to the Transport
Services implementation -- it is not guaranteed that a Message will Services implementation - it is not guaranteed that a Message will
not be sent when its Lifetime has expired. not be sent when its Lifetime has expired.
Setting a Message's Lifetime to infinite indicates that the Setting a Message's Lifetime to infinite indicates that the
application does not wish to apply a time constraint on the application does not wish to apply a time constraint on the
transmission of the Message, but it does not express a need for transmission of the Message, but it does not express a need for
reliable delivery; reliability is adjustable per Message via the reliable delivery; reliability is adjustable per Message via the
Reliable Data Transfer (Message) property (see Section 9.1.3.7). The Reliable Data Transfer (Message) property (see Section 9.1.3.7). The
type and units of Lifetime are implementation-specific. type and units of Lifetime are implementation-specific.
9.1.3.2. Priority 9.1.3.2. Priority
skipping to change at page 60, line 16 skipping to change at page 60, line 36
Send Action will be preserved on delivery via Receive<> events for Send Action will be preserved on delivery via Receive<> events for
all Messages on a Connection that have this Message Property set to all Messages on a Connection that have this Message Property set to
true. true.
If false, the Message is delivered to the receiving application If false, the Message is delivered to the receiving application
without preserving the ordering. This property is used for protocols without preserving the ordering. This property is used for protocols
that support preservation of data ordering, see Section 6.2.4, but that support preservation of data ordering, see Section 6.2.4, but
allow out-of-order delivery for certain messages, e.g., by allow out-of-order delivery for certain messages, e.g., by
multiplexing independent messages onto different streams. multiplexing independent messages onto different streams.
If it is not configured by the application before sending, this
property's default value will be based on the Selection Property
preserveOrder of the Connection associated with the Send Action.
9.1.3.4. Safely Replayable 9.1.3.4. Safely Replayable
Name: safelyReplayable Name: safelyReplayable
Type: Boolean Type: Boolean
Default: false Default: false
If true, Safely Replayable specifies that a Message is safe to send If true, Safely Replayable specifies that a Message is safe to send
to the Remote Endpoint more than once for a single Send Action. It to the Remote Endpoint more than once for a single Send Action. It
skipping to change at page 62, line 5 skipping to change at page 62, line 26
on the other side without corruption. Changing the Reliable Data on the other side without corruption. Changing the Reliable Data
Transfer property on Messages is only possible for Connections that Transfer property on Messages is only possible for Connections that
were established enabling the Selection Property Configure Per- were established enabling the Selection Property Configure Per-
Message Reliability. When this is not the case, changing msgReliable Message Reliability. When this is not the case, changing msgReliable
will generate an error. will generate an error.
Disabling this property indicates that the Transport Services system Disabling this property indicates that the Transport Services system
may disable retransmissions or other reliability mechanisms for this may disable retransmissions or other reliability mechanisms for this
particular Message, but such disabling is not guaranteed. particular Message, but such disabling is not guaranteed.
If it is not configured by the application before sending, this
property's default value will be based on the Selection Property
reliability of the Connection associated with the Send Action.
9.1.3.8. Message Capacity Profile Override 9.1.3.8. Message Capacity Profile Override
Name: msgCapacityProfile Name: msgCapacityProfile
Type: Enumeration Type: Enumeration
Default: inherited from the Connection Property connCapacityProfile Default: inherited from the Connection Property connCapacityProfile
(Section 8.1.6) (Section 8.1.6)
This enumerated property specifies the application's preferred This enumerated property specifies the application's preferred
tradeoffs for sending this Message; it is a per-Message override of tradeoffs for sending this Message; it is a per-Message override of
the Capacity Profile connection property (see Section 8.1.6). the Capacity Profile connection property (see Section 8.1.6). If it
is not configured by the application before sending, this property's
default value will be based on the Connection Property
connCapacityProfile of the Connection associated with the Send
Action.
9.1.3.9. No Network-Layer Fragmentation 9.1.3.9. No Network-Layer Fragmentation
Name: noFragmentation Name: noFragmentation
Type: Boolean Type: Boolean
Default: false Default: false
This property specifies that a message should be sent and received This property specifies that a message should be sent and received
without network-layer fragmentation, if possible. It can be used to without network-layer fragmentation, if possible. It can be used to
avoid network layer fragmentation when transport segmentation is avoid network layer fragmentation when transport segmentation is
prefered. prefered.
This only takes effect when the transport uses a network layer that This only takes effect when the transport uses a network layer that
supports this functionality. When it does take effect, setting this supports this functionality. When it does take effect, setting this
property to true will cause the sender to avoid network-layer source property to true will cause the sender to avoid network-layer source
skipping to change at page 77, line 37 skipping to change at page 78, line 37
and Jason Lee for initial work on the Post Sockets interface, from and Jason Lee for initial work on the Post Sockets interface, from
which this work has evolved. Thanks to Maximilian Franke for asking which this work has evolved. Thanks to Maximilian Franke for asking
good questions based on implementation experience and for good questions based on implementation experience and for
contributing text, e.g., on multicast. contributing text, e.g., on multicast.
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-taps-arch] [I-D.ietf-taps-arch]
Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., and
Perkins, C., Tiesel, P. S., and C. A. Wood, "An C. Perkins, "An Architecture for Transport Services", Work
Architecture for Transport Services", Work in Progress, in Progress, Internet-Draft, draft-ietf-taps-arch-12, 3
Internet-Draft, draft-ietf-taps-arch-11, 12 July 2021, January 2022, <https://www.ietf.org/archive/id/draft-ietf-
<https://datatracker.ietf.org/doc/html/draft-ietf-taps- taps-arch-12.txt>.
arch-11>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000, RFC 2914, DOI 10.17487/RFC2914, September 2000,
<https://www.rfc-editor.org/rfc/rfc2914>. <https://www.rfc-editor.org/info/rfc2914>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/rfc/rfc4941>.
[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers",
BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017,
<https://www.rfc-editor.org/rfc/rfc8084>. <https://www.rfc-editor.org/info/rfc8084>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/rfc/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of [RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of
Transport Features Provided by IETF Transport Protocols", Transport Features Provided by IETF Transport Protocols",
RFC 8303, DOI 10.17487/RFC8303, February 2018, RFC 8303, DOI 10.17487/RFC8303, February 2018,
<https://www.rfc-editor.org/rfc/rfc8303>. <https://www.rfc-editor.org/info/rfc8303>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
"Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6", RFC 8981,
DOI 10.17487/RFC8981, February 2021,
<https://www.rfc-editor.org/info/rfc8981>.
15.2. Informative References 15.2. Informative References
[I-D.ietf-httpbis-priority] [I-D.ietf-httpbis-priority]
Oku, K. and L. Pardue, "Extensible Prioritization Scheme Oku, K. and L. Pardue, "Extensible Prioritization Scheme
for HTTP", Work in Progress, Internet-Draft, draft-ietf- for HTTP", Work in Progress, Internet-Draft, draft-ietf-
httpbis-priority-11, 8 December 2021, httpbis-priority-12, 17 January 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- <https://www.ietf.org/archive/id/draft-ietf-httpbis-
priority-11>. priority-12.txt>.
[I-D.ietf-taps-impl] [I-D.ietf-taps-impl]
Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K., Brunstrom, A., Pauly, T., Enghardt, T., Tiesel, P. S., and
Jones, T., Tiesel, P. S., Perkins, C., and M. Welzl, M. Welzl, "Implementing Interfaces to Transport Services",
"Implementing Interfaces to Transport Services", Work in Work in Progress, Internet-Draft, draft-ietf-taps-impl-11,
Progress, Internet-Draft, draft-ietf-taps-impl-10, 12 July 9 January 2022, <https://www.ietf.org/archive/id/draft-
2021, <https://datatracker.ietf.org/doc/html/draft-ietf- ietf-taps-impl-11.txt>.
taps-impl-10>.
[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, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/rfc/rfc2474>. <https://www.rfc-editor.org/info/rfc2474>.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, "Assured Forwarding PHB Group", RFC 2597,
DOI 10.17487/RFC2597, June 1999, DOI 10.17487/RFC2597, June 1999,
<https://www.rfc-editor.org/rfc/rfc2597>. <https://www.rfc-editor.org/info/rfc2597>.
[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le [RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le
Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D. Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
<https://www.rfc-editor.org/rfc/rfc3246>. <https://www.rfc-editor.org/info/rfc3246>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/rfc/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<https://www.rfc-editor.org/rfc/rfc3376>. <https://www.rfc-editor.org/info/rfc3376>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, Guidelines for DiffServ Service Classes", RFC 4594,
DOI 10.17487/RFC4594, August 2006, DOI 10.17487/RFC4594, August 2006,
<https://www.rfc-editor.org/rfc/rfc4594>. <https://www.rfc-editor.org/info/rfc4594>.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source- Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, Specific Multicast", RFC 4604, DOI 10.17487/RFC4604,
August 2006, <https://www.rfc-editor.org/rfc/rfc4604>. August 2006, <https://www.rfc-editor.org/info/rfc4604>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010, DOI 10.17487/RFC5245, April 2010,
<https://www.rfc-editor.org/rfc/rfc5245>. <https://www.rfc-editor.org/info/rfc5245>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option",
RFC 5482, DOI 10.17487/RFC5482, March 2009, RFC 5482, DOI 10.17487/RFC5482, March 2009,
<https://www.rfc-editor.org/rfc/rfc5482>. <https://www.rfc-editor.org/info/rfc5482>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5766, April 2010,
<https://www.rfc-editor.org/rfc/rfc5766>.
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
Services Code Point (DSCP) for Capacity-Admitted Traffic", Services Code Point (DSCP) for Capacity-Admitted Traffic",
RFC 5865, DOI 10.17487/RFC5865, May 2010, RFC 5865, DOI 10.17487/RFC5865, May 2010,
<https://www.rfc-editor.org/rfc/rfc5865>. <https://www.rfc-editor.org/info/rfc5865>.
[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
Time Communication Use Cases and Requirements", RFC 7478, Time Communication Use Cases and Requirements", RFC 7478,
DOI 10.17487/RFC7478, March 2015, DOI 10.17487/RFC7478, March 2015,
<https://www.rfc-editor.org/rfc/rfc7478>. <https://www.rfc-editor.org/info/rfc7478>.
[RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain
Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
<https://www.rfc-editor.org/rfc/rfc7556>. <https://www.rfc-editor.org/info/rfc7556>.
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services
(Diffserv) and Real-Time Communication", RFC 7657, (Diffserv) and Real-Time Communication", RFC 7657,
DOI 10.17487/RFC7657, November 2015, DOI 10.17487/RFC7657, November 2015,
<https://www.rfc-editor.org/rfc/rfc7657>. <https://www.rfc-editor.org/info/rfc7657>.
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
Ed., "Services Provided by IETF Transport Protocols and Ed., "Services Provided by IETF Transport Protocols and
Congestion Control Mechanisms", RFC 8095, Congestion Control Mechanisms", RFC 8095,
DOI 10.17487/RFC8095, March 2017, DOI 10.17487/RFC8095, March 2017,
<https://www.rfc-editor.org/rfc/rfc8095>. <https://www.rfc-editor.org/info/rfc8095>.
[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
August 2017, <https://www.rfc-editor.org/rfc/rfc8229>. August 2017, <https://www.rfc-editor.org/info/rfc8229>.
[RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, [RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,
"Stream Schedulers and User Message Interleaving for the "Stream Schedulers and User Message Interleaving for the
Stream Control Transmission Protocol", RFC 8260, Stream Control Transmission Protocol", RFC 8260,
DOI 10.17487/RFC8260, November 2017, DOI 10.17487/RFC8260, November 2017,
<https://www.rfc-editor.org/rfc/rfc8260>. <https://www.rfc-editor.org/info/rfc8260>.
[RFC8293] Ghanwani, A., Dunbar, L., McBride, M., Bannai, V., and R. [RFC8293] Ghanwani, A., Dunbar, L., McBride, M., Bannai, V., and R.
Krishnan, "A Framework for Multicast in Network Krishnan, "A Framework for Multicast in Network
Virtualization over Layer 3", RFC 8293, Virtualization over Layer 3", RFC 8293,
DOI 10.17487/RFC8293, January 2018, DOI 10.17487/RFC8293, January 2018,
<https://www.rfc-editor.org/rfc/rfc8293>. <https://www.rfc-editor.org/info/rfc8293>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>.
[RFC8489] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, [RFC8489] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing,
D., Mahy, R., and P. Matthews, "Session Traversal D., Mahy, R., and P. Matthews, "Session Traversal
Utilities for NAT (STUN)", RFC 8489, DOI 10.17487/RFC8489, Utilities for NAT (STUN)", RFC 8489, DOI 10.17487/RFC8489,
February 2020, <https://www.rfc-editor.org/rfc/rfc8489>. February 2020, <https://www.rfc-editor.org/info/rfc8489>.
[RFC8546] Trammell, B. and M. Kuehlewind, "The Wire Image of a [RFC8546] Trammell, B. and M. Kuehlewind, "The Wire Image of a
Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April
2019, <https://www.rfc-editor.org/rfc/rfc8546>. 2019, <https://www.rfc-editor.org/info/rfc8546>.
[RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for [RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for
Differentiated Services", RFC 8622, DOI 10.17487/RFC8622, Differentiated Services", RFC 8622, DOI 10.17487/RFC8622,
June 2019, <https://www.rfc-editor.org/rfc/rfc8622>. June 2019, <https://www.rfc-editor.org/info/rfc8622>.
[RFC8656] Reddy, T., Ed., Johnston, A., Ed., Matthews, P., and J.
Rosenberg, "Traversal Using Relays around NAT (TURN):
Relay Extensions to Session Traversal Utilities for NAT
(STUN)", RFC 8656, DOI 10.17487/RFC8656, February 2020,
<https://www.rfc-editor.org/info/rfc8656>.
[RFC8699] Islam, S., Welzl, M., and S. Gjessing, "Coupled Congestion [RFC8699] Islam, S., Welzl, M., and S. Gjessing, "Coupled Congestion
Control for RTP Media", RFC 8699, DOI 10.17487/RFC8699, Control for RTP Media", RFC 8699, DOI 10.17487/RFC8699,
January 2020, <https://www.rfc-editor.org/rfc/rfc8699>. January 2020, <https://www.rfc-editor.org/info/rfc8699>.
[RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: [RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE:
Incremental Provisioning of Candidates for the Interactive Incremental Provisioning of Candidates for the Interactive
Connectivity Establishment (ICE) Protocol", RFC 8838, Connectivity Establishment (ICE) Protocol", RFC 8838,
DOI 10.17487/RFC8838, January 2021, DOI 10.17487/RFC8838, January 2021,
<https://www.rfc-editor.org/rfc/rfc8838>. <https://www.rfc-editor.org/info/rfc8838>.
[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
Völker, "Packetization Layer Path MTU Discovery for Völker, "Packetization Layer Path MTU Discovery for
Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
September 2020, <https://www.rfc-editor.org/rfc/rfc8899>. September 2020, <https://www.rfc-editor.org/info/rfc8899>.
[RFC8922] Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C. [RFC8922] Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C.
Wood, "A Survey of the Interaction between Security Wood, "A Survey of the Interaction between Security
Protocols and Transport Services", RFC 8922, Protocols and Transport Services", RFC 8922,
DOI 10.17487/RFC8922, October 2020, DOI 10.17487/RFC8922, October 2020,
<https://www.rfc-editor.org/rfc/rfc8922>. <https://www.rfc-editor.org/info/rfc8922>.
[RFC8923] Welzl, M. and S. Gjessing, "A Minimal Set of Transport [RFC8923] Welzl, M. and S. Gjessing, "A Minimal Set of Transport
Services for End Systems", RFC 8923, DOI 10.17487/RFC8923, Services for End Systems", RFC 8923, DOI 10.17487/RFC8923,
October 2020, <https://www.rfc-editor.org/rfc/rfc8923>. October 2020, <https://www.rfc-editor.org/info/rfc8923>.
[TCP-COUPLING] [TCP-COUPLING]
Islam, S., Welzl, M., Hiorth, K., Hayes, D., Armitage, G., Islam, S., Welzl, M., Hiorth, K., Hayes, D., Armitage, G.,
and S. Gjessing, "ctrlTCP: Reducing Latency through and S. Gjessing, "ctrlTCP: Reducing Latency through
Coupled, Heterogeneous Multi-Flow TCP Congestion Control", Coupled, Heterogeneous Multi-Flow TCP Congestion Control",
IEEE INFOCOM Global Internet Symposium (GI) workshop (GI IEEE INFOCOM Global Internet Symposium (GI) workshop (GI
2018) , 2018. 2018) , 2018.
Appendix A. Implementation Mapping Appendix A. Implementation Mapping
skipping to change at page 88, line 12 skipping to change at page 89, line 41
* Notification of Excessive Retransmissions (early warning below * Notification of Excessive Retransmissions (early warning below
abortion threshold): SoftError Event (Section 8.3.1). abortion threshold): SoftError Event (Section 8.3.1).
Authors' Addresses Authors' Addresses
Brian Trammell (editor) Brian Trammell (editor)
Google Switzerland GmbH Google Switzerland GmbH
Gustav-Gull-Platz 1 Gustav-Gull-Platz 1
CH- 8004 Zurich CH- 8004 Zurich
Switzerland Switzerland
Email: ietf@trammell.ch Email: ietf@trammell.ch
Michael Welzl (editor) Michael Welzl (editor)
University of Oslo University of Oslo
PO Box 1080 Blindern PO Box 1080 Blindern
0316 Oslo 0316 Oslo
Norway Norway
Email: michawe@ifi.uio.no Email: michawe@ifi.uio.no
Theresa Enghardt Theresa Enghardt
Netflix Netflix
121 Albright Way 121 Albright Way
Los Gatos, CA 95032, Los Gatos, CA 95032,
United States of America United States of America
Email: ietf@tenghardt.net Email: ietf@tenghardt.net
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
Fraser Noble Building Fraser Noble Building
Aberdeen, AB24 3UE Aberdeen, AB24 3UE
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/ URI: http://www.erg.abdn.ac.uk/
Mirja Kuehlewind Mirja Kuehlewind
Ericsson Ericsson
Ericsson-Allee 1 Ericsson-Allee 1
Herzogenrath Herzogenrath
Germany Germany
Email: mirja.kuehlewind@ericsson.com Email: mirja.kuehlewind@ericsson.com
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
School of Computing Science School of Computing Science
Glasgow G12 8QQ Glasgow G12 8QQ
United Kingdom United Kingdom
Email: csp@csperkins.org Email: csp@csperkins.org
Philipp S. Tiesel Philipp S. Tiesel
SAP SE SAP SE
Konrad-Zuse-Ring 10 Konrad-Zuse-Ring 10
14469 Potsdam 14469 Potsdam
Germany Germany
Email: philipp@tiesel.net Email: philipp@tiesel.net
Christopher A. Wood
Cloudflare
101 Townsend St
San Francisco,
United States of America
Email: caw@heapingbits.net
Tommy Pauly Tommy Pauly
Apple Inc. Apple Inc.
One Apple Park Way One Apple Park Way
Cupertino, California 95014, Cupertino, California 95014,
United States of America United States of America
Email: tpauly@apple.com Email: tpauly@apple.com
Kyle Rose
Akamai Technologies, Inc.
145 Broadway
Cambridge, MA,
United States of America
Email: krose@krose.org
 End of changes. 89 change blocks. 
160 lines changed or deleted 175 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/