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/ |