rfc9623v2.txt | rfc9623.txt | |||
---|---|---|---|---|
skipping to change at line 650 ¶ | skipping to change at line 650 ¶ | |||
nodes on branches with higher rankings represent connection attempts | nodes on branches with higher rankings represent connection attempts | |||
that will be raced first. | that will be raced first. | |||
In addition to the properties provided by the application, an | In addition to the properties provided by the application, an | |||
implementation may include additional criteria such as cached | implementation may include additional criteria such as cached | |||
performance estimates (see Section 9.2) or system policy (see | performance estimates (see Section 9.2) or system policy (see | |||
Section 3.2) in the ranking. Two examples of how Selection and | Section 3.2) in the ranking. Two examples of how Selection and | |||
Connection Properties may be used to sort branches are provided | Connection Properties may be used to sort branches are provided | |||
below: | below: | |||
"Interface Instance or Type" (property name interface): If the | "Interface Instance or Type" (property name interface): | |||
application specifies an interface type to be preferred or | If the application specifies an interface type to be preferred or | |||
avoided, implementations should accordingly rank the paths. If | avoided, implementations should accordingly rank the paths. If | |||
the application specifies an interface type to be required or | the application specifies an interface type to be required or | |||
prohibited, an implementation is expected to exclude the | prohibited, an implementation is expected to exclude the | |||
nonconforming paths. | nonconforming paths. | |||
"Capacity Profile" (property name connCapacityProfile): An implement | "Capacity Profile" (property name connCapacityProfile): | |||
ation can use the capacity profile to prefer paths that match an | An implementation can use the capacity profile to prefer paths | |||
application's expected traffic profile. This match will use | that match an application's expected traffic profile. This match | |||
cached performance estimates; see Section 9.2. Some examples of | will use cached performance estimates; see Section 9.2. Some | |||
path preferences based on capacity profiles include: | examples of path preferences based on capacity profiles include: | |||
Low Latency/Interactive: Prefer paths with the lowest expected | Low Latency/Interactive: Prefer paths with the lowest expected | |||
Round-Trip Time (RTT), based on observed RTT estimates; | Round-Trip Time (RTT), based on observed RTT estimates; | |||
Low Latency/Non-Interactive: Prefer paths with a low expected | Low Latency/Non-Interactive: Prefer paths with a low expected | |||
Round-Trip Time (RTT) and possible delay variation; | Round-Trip Time (RTT) and possible delay variation; | |||
Constant-Rate Streaming: Prefer paths that are expected to | Constant-Rate Streaming: Prefer paths that are expected to | |||
satisfy the requested stream send or receive bitrate based on | satisfy the requested stream send or receive bitrate based on | |||
the observed maximum throughput; | the observed maximum throughput; | |||
skipping to change at line 962 ¶ | skipping to change at line 962 ¶ | |||
Transport Services system should report an EstablishmentError to the | Transport Services system should report an EstablishmentError to the | |||
application. An EstablishmentError event should also be generated if | application. An EstablishmentError event should also be generated if | |||
the Transport Services system finds no usable candidates to race. | the Transport Services system finds no usable candidates to race. | |||
4.5. Establishing Multiplexed Connections | 4.5. Establishing Multiplexed Connections | |||
Multiplexing several Connections over a single underlying transport | Multiplexing several Connections over a single underlying transport | |||
connection requires that the multiplexed Connections belong to the | connection requires that the multiplexed Connections belong to the | |||
same Connection Group (as is indicated by the application using the | same Connection Group (as is indicated by the application using the | |||
Clone action). When the underlying transport connection supports | Clone action). When the underlying transport connection supports | |||
multi-streaming, the Transport Services System can map each | multistreaming, the Transport Services System can map each Connection | |||
Connection in the Connection Group to a different stream of this | in the Connection Group to a different stream of this connection. | |||
connection. | ||||
For such streams, there is often no explicit connection establishment | For such streams, there is often no explicit connection establishment | |||
procedure for the new stream prior to sending data on it (e.g., with | procedure for the new stream prior to sending data on it (e.g., with | |||
SCTP). In this case, the same considerations apply to determining | SCTP). In this case, the same considerations apply to determining | |||
stream establishment as apply to establishing a UDP connection, as | stream establishment as apply to establishing a UDP connection, as | |||
discussed in Section 4.4.1. This means that there might not be any | discussed in Section 4.4.1. This means that there might not be any | |||
"establishment" message (like a TCP SYN). | "establishment" message (like a TCP SYN). | |||
4.6. Handling Connectionless Protocols | 4.6. Handling Connectionless Protocols | |||
skipping to change at line 1517 ¶ | skipping to change at line 1516 ¶ | |||
When protocol instances in the Protocol Stack report generic or | When protocol instances in the Protocol Stack report generic or | |||
protocol-specific errors, the API will deliver them to the | protocol-specific errors, the API will deliver them to the | |||
application as SoftError events. These allow the application to be | application as SoftError events. These allow the application to be | |||
informed of ICMP errors and other similar events. | informed of ICMP errors and other similar events. | |||
7.1. Pooled Connection | 7.1. Pooled Connection | |||
For applications that do not need in-order delivery of Messages, the | For applications that do not need in-order delivery of Messages, the | |||
Transport Services Implementation may distribute Messages of a single | Transport Services Implementation may distribute Messages of a single | |||
Connection across several underlying transport connections or | Connection across several underlying transport connections or | |||
multiple streams of multi-streaming connections between endpoints, as | multiple streams of multistreaming connections between endpoints, as | |||
long as all of these satisfy the Selection Properties. The Transport | long as all of these satisfy the Selection Properties. The Transport | |||
Services Implementation will then hide this connection management and | Services Implementation will then hide this connection management and | |||
only expose a single Connection object, which we call a "Pooled | only expose a single Connection object, which we call a "Pooled | |||
Connection". This is in contrast to Connection Groups, which | Connection". This is in contrast to Connection Groups, which | |||
explicitly expose combined treatment of Connections, giving the | explicitly expose combined treatment of Connections, giving the | |||
application control over multiplexing, for example. | application control over multiplexing, for example. | |||
Pooled Connections can be useful when the application using the | Pooled Connections can be useful when the application using the | |||
Transport Services system implements a protocol such as HTTP, which | Transport Services system implements a protocol such as HTTP, which | |||
employs request/response pairs and does not require in-order delivery | employs request/response pairs and does not require in-order delivery | |||
skipping to change at line 1604 ¶ | skipping to change at line 1603 ¶ | |||
exposed to the application. The strategy to do so is implementation | exposed to the application. The strategy to do so is implementation | |||
specific, but it should be consistent with the behavior of multipath | specific, but it should be consistent with the behavior of multipath | |||
transports. | transports. | |||
8. Implementing Connection Termination | 8. Implementing Connection Termination | |||
For Close (which leads to a Closed event) and Abort (which leads to a | For Close (which leads to a Closed event) and Abort (which leads to a | |||
ConnectionError event), the application might find it useful to be | ConnectionError event), the application might find it useful to be | |||
informed when a peer closes or aborts a Connection. Whether this is | informed when a peer closes or aborts a Connection. Whether this is | |||
possible depends on the underlying protocol, and no guarantees can be | possible depends on the underlying protocol, and no guarantees can be | |||
given. When an underlying transport connection supports multi- | given. When an underlying transport connection supports | |||
streaming (such as SCTP), the Transport Services system can use a | multistreaming (such as SCTP), the Transport Services system can use | |||
stream reset procedure to cause a Finish event upon a Close action | a stream reset procedure to cause a Finish event upon a Close action | |||
from the peer [NEAT-flow-mapping]. | from the peer [NEAT-flow-mapping]. | |||
9. Cached State | 9. Cached State | |||
Beyond a single Connection's lifetime, it is useful for an | Beyond a single Connection's lifetime, it is useful for an | |||
implementation to keep state and history. This cached state can help | implementation to keep state and history. This cached state can help | |||
improve future Connection establishment due to reusing results and | improve future Connection establishment due to reusing results and | |||
credentials and favoring paths and protocols that performed well in | credentials and favoring paths and protocols that performed well in | |||
the past. | the past. | |||
skipping to change at line 1681 ¶ | skipping to change at line 1680 ¶ | |||
* Connection establishment success rate | * Connection establishment success rate | |||
These items can be cached on a per-address and per-subnet granularity | These items can be cached on a per-address and per-subnet granularity | |||
and averaged between different values. The information should be | and averaged between different values. The information should be | |||
cached on a per-network basis since it is expected that different | cached on a per-network basis since it is expected that different | |||
network attachments will have different performance characteristics. | network attachments will have different performance characteristics. | |||
Besides Protocol Instances, other system entities may also provide | Besides Protocol Instances, other system entities may also provide | |||
data into performance-oriented caches. This could for instance be | data into performance-oriented caches. This could for instance be | |||
signal strength information reported by radio modems like Wi-Fi and | signal strength information reported by radio modems like Wi-Fi and | |||
mobile broadband or information about the battery-level of the | mobile broadband or information about the battery level of the | |||
device. Furthermore, the system may cache the observed maximum | device. Furthermore, the system may cache the observed maximum | |||
throughput on a path as an estimate of the available bandwidth. | throughput on a path as an estimate of the available bandwidth. | |||
An implementation should use this information, when possible, to | An implementation should use this information, when possible, to | |||
influence preference between candidate paths, endpoints, and protocol | influence preference between candidate paths, endpoints, and protocol | |||
options. Eligible options that historically had significantly better | options. Eligible options that historically had significantly better | |||
performance than others should be selected first when gathering | performance than others should be selected first when gathering | |||
candidates (see Section 4.2) to ensure better performance for the | candidates (see Section 4.2) to ensure better performance for the | |||
application. | application. | |||
skipping to change at line 2545 ¶ | skipping to change at line 2544 ¶ | |||
Tommy Pauly (editor) | Tommy Pauly (editor) | |||
Apple Inc. | Apple Inc. | |||
One Apple Park Way | One Apple Park Way | |||
Cupertino, CA 95014 | Cupertino, CA 95014 | |||
United States of America | United States of America | |||
Email: tpauly@apple.com | Email: tpauly@apple.com | |||
Reese Enghardt | Reese Enghardt | |||
Netflix | Netflix | |||
121 Albright Way | 121 Albright Way | |||
Los Gatos, California 95032 | Los Gatos, CA 95032 | |||
United States of America | United States of America | |||
Email: ietf@tenghardt.net | Email: ietf@tenghardt.net | |||
Philipp S. Tiesel | Philipp S. Tiesel | |||
SAP SE | SAP SE | |||
George-Stephenson-Str. 7-13 | George-Stephenson-Str. 7-13 | |||
10557 Berlin | 10557 Berlin | |||
Germany | Germany | |||
Email: philipp@tiesel.net | Email: philipp@tiesel.net | |||
End of changes. 7 change blocks. | ||||
16 lines changed or deleted | 15 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |