rfc8923_6.1.original | rfc8923_dectree.txt | |||
---|---|---|---|---|
- Will it ever be necessary to offer any of the following? | +----------------------------------------------------------+ | |||
* Reliably transfer data | | Will it ever be necessary to offer any of the following? | | |||
* Notify the peer of closing/aborting | | * Reliably transfer data | | |||
* Preserve data ordering | | * Notify the peer of closing/aborting | | |||
| * Preserve data ordering | | ||||
Yes: SCTP or TCP can be used. | +----------------------------------------------------------+ | |||
- Is any of the following useful to the application? | | | | |||
* Choosing a scheduler to operate between connections | |Yes |No | |||
in a group, with the possibility to configure a priority | | | | |||
or weight per connection | V V | |||
* Configurable message reliability | +--------------------------------------+ +-----------------------------+ | |||
* Unordered message delivery | | Is any of the following useful to | | Is any of the following | | |||
* Request not to delay the acknowledgement (SACK) of a message | | the application? | | useful to the application? | | |||
| * Choosing a scheduler to operate | | * Specify checksum coverage | | ||||
Yes: SCTP is preferred. | | between connections in a group, | | used by the sender | | |||
No: | | with the possibility to configure | | * Specify minimum checksum | | |||
- Is any of the following useful to the application? | | a priority or weight per connection| | coverage required by the | | |||
* Hand over a message to reliably transfer (possibly | | * Configurable message reliability | | receiver | | |||
multiple times) before connection establishment | | * Unordered message delivery | +-----------------------------+ | |||
* Suggest timeout to the peer | | * Request not to delay the | | | | |||
* Notification of Excessive Retransmissions (early | | acknowledgement (SACK) of a message| |Yes |No | |||
warning below abortion threshold) | +--------------------------------------+ | | | |||
* Notification of ICMP error message arrival | | | | | | |||
|Yes |No | | | ||||
Yes: TCP is preferred. | V | V V | |||
No: SCTP and TCP are equally preferable. | SCTP is | UDP-Lite is UDP is | |||
preferred. | preferred. preferred. | ||||
No: all protocols can be used. | V | |||
- Is any of the following useful to the application? | +------------------------------------------------------+ | |||
* Specify checksum coverage used by the sender | | Is any of the following useful to the application? | | |||
* Specify minimum checksum coverage required by receiver | | * Hand over a message to reliably transfer (possibly | | |||
| multiple times) before connection establishment | | ||||
Yes: UDP-Lite is preferred. | | * Suggest timeout to the peer | | |||
No: UDP is preferred. | | * Notification of Excessive Retransmissions (early | | |||
| warning below abortion threshold) | | ||||
| * Notification of ICMP error message arrival | | ||||
+------------------------------------------------------+ | ||||
| | | ||||
|Yes |No | ||||
V V | ||||
TCP is preferred. SCTP and TCP | ||||
are equally preferable. | ||||
End of changes. 1 change blocks. | ||||
lines changed or deleted | lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |