idnits 2.17.1 draft-ietf-taps-transports-usage-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 13 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 5, 2017) is 2576 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SUBCATEGORY' is mentioned on line 845, but not defined == Unused Reference: 'RFC2119' is defined on line 2080, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-taps-transports-usage-udp-00 == Outdated reference: A later version (-13) exists of draft-ietf-tsvwg-sctp-ndata-08 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) ** Obsolete normative reference: RFC 7053 (Obsoleted by RFC 9260) == Outdated reference: A later version (-05) exists of draft-gjessing-taps-minset-04 -- Obsolete informational reference (is this intentional?): RFC 6093 (Obsoleted by RFC 9293) Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TAPS M. Welzl 3 Internet-Draft University of Oslo 4 Intended status: Informational M. Tuexen 5 Expires: October 7, 2017 Muenster Univ. of Appl. Sciences 6 N. Khademi 7 University of Oslo 8 April 5, 2017 10 On the Usage of Transport Features Provided by IETF Transport Protocols 11 draft-ietf-taps-transports-usage-04 13 Abstract 15 This document describes how TCP, MPTCP, SCTP, UDP and UDP-Lite expose 16 services to applications and how an application can configure and use 17 the transport features that make up these services. It also 18 discusses the service provided by the LEDBAT congestion control 19 mechanism. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 7, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Pass 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. Primitives Provided by TCP . . . . . . . . . . . . . . . . 5 59 3.1.1. Excluded Primitives or Parameters . . . . . . . . . . 8 60 3.2. Primitives Provided by MPTCP . . . . . . . . . . . . . . . 9 61 3.3. Primitives Provided by SCTP . . . . . . . . . . . . . . . 10 62 3.3.1. Excluded Primitives or Parameters . . . . . . . . . . 17 63 3.4. Primitives Provided by UDP and UDP-Lite . . . . . . . . . 18 64 3.5. The service of LEDBAT . . . . . . . . . . . . . . . . . . 18 65 4. Pass 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 66 4.1. CONNECTION Related Primitives . . . . . . . . . . . . . . 20 67 4.2. DATA Transfer Related Primitives . . . . . . . . . . . . . 31 68 5. Pass 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 69 5.1. CONNECTION Related Transport Features . . . . . . . . . . 34 70 5.2. DATA Transfer Related Transport Features . . . . . . . . . 40 71 5.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . . 40 72 5.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . . 41 73 5.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . 41 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 78 9.1. Normative References . . . . . . . . . . . . . . . . . . . 42 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 45 80 Appendix A. Overview of RFCs used as input for pass 1 . . . . . . 46 81 Appendix B. How this document was developed . . . . . . . . . . . 46 82 Appendix C. Revision information . . . . . . . . . . . . . . . . 48 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 85 1. Terminology 87 Transport Feature: a specific end-to-end feature that the transport 88 layer provides to an application. Examples include 89 confidentiality, reliable delivery, ordered delivery, message- 90 versus-stream orientation, etc. 91 Transport Service: a set of Transport Features, without an 92 association to any given framing protocol, which provides a 93 complete service to an application. 94 Transport Protocol: an implementation that provides one or more 95 different transport services using a specific framing and header 96 format on the wire. 97 Transport Protocol Component: an implementation of a Transport 98 Feature within a protocol. 99 Transport Service Instance: an arrangement of transport protocols 100 with a selected set of features and configuration parameters that 101 implements a single transport service, e.g., a protocol stack (RTP 102 over UDP). 103 Application: an entity that uses the transport layer for end-to-end 104 delivery of data across the network (this may also be an upper 105 layer protocol or tunnel encapsulation). 106 Endpoint: an entity that communicates with one or more other 107 endpoints using a transport protocol. 108 Connection: shared state of two or more endpoints that persists 109 across messages that are transmitted between these endpoints. 110 Primitive: a function call that is used to locally communicate 111 between an application and a transport endpoint and is related to 112 one or more Transport Features. 113 Parameter: a value passed between an application and a transport 114 protocol by a primitive. 115 Socket: the combination of a destination IP address and a 116 destination port number. 117 Transport Address: the combination of an IP address, transport 118 protocol and the port number used by the transport protocol. 120 2. Introduction 122 This document presents defined interactions between applications and 123 the transport protocols TCP, MPTCP, SCTP, UDP and UDP-Lite as well as 124 the LEDBAT congestion control mechanism in the form of primitives and 125 Transport Features. Primitives can be invoked by an application or a 126 transport protocol; the latter type is called an "event". The list 127 of primitives and Transport Features in this document is strictly 128 based on the parts of protocol specifications that describe what the 129 protocol provides to an application using it and how the application 130 interacts with it. Together with [RFC8095], it provides the basis 131 for the minimal set of transport services that end systems should 132 support; this minimal set is derived in 133 [I-D.draft-gjessing-taps-minset]. 135 Parts of a protocol that are explicitly stated as optional to 136 implement are not covered. Interactions between the application and 137 a transport protocol that are not directly related to the operation 138 of the protocol are also not covered. For example, [RFC6458] 139 explains how an application can use socket options to indicate its 140 interest in receiving certain notifications. However, for the 141 purpose of identifying primitives and Transport Services, the ability 142 to enable or disable the reception of notifications is irrelevant. 143 Similarly, one-to-many style sockets described in [RFC6458] just 144 affect the application programming style, not how the underlying 145 protocol operates, and they are therefore not discussed here. The 146 same is true for the ability to obtain the unchanged value of a 147 parameter that an application has previously set (this is the case 148 for the "get" in many get/set operations in [RFC6458]). 150 The document presents a three-pass process to arrive at a list of 151 Transport Features. In the first pass, the relevant RFC text is 152 discussed per protocol. In the second pass, this discussion is used 153 to derive a list of primitives that are uniformly categorized across 154 protocols. Here, an attempt is made to present or -- where text 155 describing primitives does not yet exist -- construct primitives in a 156 slightly generalized form to highlight similarities. This is, for 157 example, achieved by renaming primitives of protocols or by avoiding 158 a strict 1:1-mapping between the primitives in the protocol 159 specification and primitives in the list. Finally, the third pass 160 presents Transport Features based on pass 2, identifying which 161 protocols implement them. 163 In the list resulting from the second pass, some Transport Features 164 are missing because they are implicit in some protocols, and they 165 only become explicit when we consider the superset of all features 166 offered by all protocols. For example, TCP always carries out 167 congestion control; we have to consider it together with a protocol 168 like UDP (which does not have congestion control) before we can 169 consider congestion control as a Transport Feature. The complete 170 list of features across all protocols is therefore only available 171 after pass 3. 173 This document discusses unicast transport protocols and a unicast 174 congestion control mechanism. Transport protocols provide 175 communication between processes that operate on network endpoints, 176 which means that they allow for multiplexing of communication between 177 the same IP addresses, and normally this multiplexing is achieved 178 using port numbers. Port multiplexing is therefore assumed to be 179 always provided and not discussed in this document. 181 Some protocols are connection-oriented. Connection-oriented 182 protocols often use an initial call to a specific transport primitive 183 to open a connection before communication can progress, and require 184 communication to be explicitly terminated by issuing another call to 185 a transport primitive (usually called "close"). A "connection" is 186 the common state that some transport primitives refer to, e.g., to 187 adjust general configuration settings. Connection establishment, 188 maintenance and termination are therefore used to categorize 189 transport primitives of connection-oriented transport protocols in 190 pass 2 and pass 3. For this purpose, UDP is assumed to be used with 191 "connected" sockets, i.e. sockets that are bound to a specific pair 192 of addresses and ports [FJ16]. 194 3. Pass 1 196 This first iteration summarizes the relevant text parts of the RFCs 197 describing the protocols, focusing on what each transport protocol 198 provides to the application and how it is used (abstract API 199 descriptions, where they are available). 201 3.1. Primitives Provided by TCP 203 [RFC0793] states: "The Transmission Control Protocol (TCP) is 204 intended for use as a highly reliable host-to-host protocol between 205 hosts in packet-switched computer communication networks, and in 206 interconnected systems of such networks". Section 3.8 in [RFC0793] 207 further specifies the interaction with the application by listing 208 several transport primitives. It is also assumed that an Operating 209 System provides a means for TCP to asynchronously signal the 210 application; the primitives representing such signals are called 211 'events' in this section. This section describes the relevant 212 primitives. 214 open: this is either active or passive, to initiate a connection or 215 listen for incoming connections. All other primitives are 216 associated with a specific connection, which is assumed to first 217 have been opened. An active open call contains a socket. A 218 passive open call with a socket waits for a particular connection; 219 alternatively, a passive open call can leave the socket 220 unspecified to accept any incoming connection. A fully specified 221 passive call can later be made active by calling 'send'. 222 Optionally, a timeout can be specified, after which TCP will abort 223 the connection if data has not been successfully delivered to the 224 destination (else a default timeout value is used). [RFC1122] 225 describes a procedure for aborting the connection that must be 226 used to avoid excessive retransmissions, and states that an 227 application must be able to control the threshold used to 228 determine the condition for aborting -- and that this threshold 229 may be measured in time units or as a count of retransmission. 230 This indicates that the timeout could also be specified as a count 231 of retransmission. 233 Also optional, for multihomed hosts, the local IP address can be 234 provided [RFC1122]. If it is not provided, a default choice will 235 be made in case of active open calls. A passive open call will 236 await incoming connection requests to all local addresses and then 237 maintain usage of the local IP address where the incoming 238 connection request has arrived. Finally, the 'options' parameter 239 is explained in [RFC1122] to allow the application to specify IP 240 options such as source route, record route, or timestamp. It is 241 not stated on which segments of a connection these options should 242 be applied, but probably all segments, as this is also stated in a 243 specification given for the usage of source route (section 4.2.3.8 244 of [RFC1122]). Source route is the only non-optional IP option in 245 this parameter, allowing an application to specify a source route 246 when it actively opens a TCP connection. 248 Master Key Tuples (MKTs) for authentication can optionally be 249 configured when calling open (section 7.1 of [RFC5925]). 251 TCP Fast Open (TFO) [RFC7413] allows to immediately hand over a 252 message from the active open to the passive open side of a TCP 253 connection together with the first message establishment packet 254 (the SYN). This can be useful for applications that are sensitive 255 to TCP's connection setup delay. TCP implementations MUST NOT use 256 TFO by default, but only use TFO if requested explicitly by the 257 application on a per-service-port basis. To benefit from TFO, the 258 first application data unit (e.g., an HTTP request) needs to be no 259 more than TCP's maximum segment size (minus options used in the 260 SYN). For the active open side, [RFC7413] recommends changing or 261 replacing the connect() call in order to support a user data 262 buffer argument. For the passive open side, the application needs 263 to enable the reception of Fast Open requests, e.g. via a new 264 TCP_FASTOPEN setsockopt() socket option before listen(). The 265 receiving application must be prepared to accept duplicates of the 266 TFO message, as the first data written to a socket can be 267 delivered more than once to the application on the remote host. 269 send: this is the primitive that an application uses to give the 270 local TCP transport endpoint a number of bytes that TCP should 271 reliably send to the other side of the connection. The URGENT 272 flag, if set, states that the data handed over by this send call 273 is urgent and this urgency should be indicated to the receiving 274 process in case the receiving application has not yet consumed all 275 non-urgent data preceding it. An optional timeout parameter can 276 be provided that updates the connection's timeout (see 'open'). 277 Additionally, optional parameters allow to indicate the preferred 278 outgoing MKT (current_key) and/or the preferred incoming MKT 279 (rnext_key) of a connection (section 7.1 of [RFC5925]). 281 receive: This primitive allocates a receiving buffer for a provided 282 number of bytes. It returns the number of received bytes provided 283 in the buffer when these bytes have been received and written into 284 the buffer by TCP. The application is informed of urgent data via 285 an URGENT flag: if it is on, there is urgent data. If it is off, 286 there is no urgent data or this call to 'receive' has returned all 287 the urgent data. The application is also informed about the 288 current_key and rnext_key information carried in a recently 289 received segment via an optional parameter (section 7.1 of 290 [RFC5925]). 292 close: This primitive closes one side of a connection. It is 293 semantically equivalent to "I have no more data to send" but does 294 not mean "I will not receive any more", as the other side may 295 still have data to send. This call reliably delivers any data 296 that has already been given to TCP (and if that fails, 'close' 297 becomes 'abort'). 299 abort: This primitive causes all pending 'send' and 'receive' calls 300 to be aborted. A TCP RESET message is sent to the TCP endpoint on 301 the other side of the connection [RFC0793]. 303 close event: TCP uses this primitive to inform an application that 304 the application on the other side has called the 'close' 305 primitive, so the local application can also issue a 'close' and 306 terminate the connection gracefully. See [RFC0793], Section 3.5. 308 abort event: When TCP aborts a connection upon receiving a "Reset" 309 from the peer, it "advises the user and goes to the CLOSED state." 310 See [RFC0793], Section 3.4. 312 USER TIMEOUT event: This event, described in Section 3.9 of 313 [RFC0793], is executed when the user timeout expires (see 'open'). 314 All queues are flushed and the application is informed that the 315 connection had to be aborted due to user timeout. 317 ERROR_REPORT event: This event, described in Section 4.2.4.1 of 318 [RFC1122], informs the application of "soft errors" that can be 319 safely ignored [RFC5461], including the arrival of an ICMP error 320 message or excessive retransmissions (reaching a threshold below 321 the threshold where the connection is aborted). 323 Type-of-Service: Section 4.2.4.2 of [RFC1122] states that the 324 application layer MUST be able to specify the Type-of-Service 325 (TOS) for segments that are sent on a connection. The application 326 should be able to change the TOS during the connection lifetime, 327 and the TOS value should be passed to the IP layer unchanged. 328 Since then the TOS field has been redefined. A part of the field 329 has been assigned to ECN [RFC3168] and the six most significant 330 bits have been assigned to carry the DiffServ CodePoint, DSField 331 [RFC3260]. Staying with the intention behind the application's 332 ability to specify the "Type of Service", this should probably be 333 interpreted to mean the value in the DSField, which is the 334 Differentiated Services Codepoint (DSCP). 336 Nagle: The Nagle algorithm, described in Section 4.2.3.4 of 337 [RFC1122], delays sending data for some time to increase the 338 likelihood of sending a full-sized segment. An application can 339 disable the Nagle algorithm for an individual connection. 341 User Timeout Option: The User Timeout Option (UTO) [RFC5482] allows 342 one end of a TCP connection to advertise its current user timeout 343 value so that the other end of the TCP connection can adapt its 344 own user timeout accordingly. In addition to the configurable 345 value of the User Timeout (see 'send'), [RFC5482] introduces three 346 per-connection state variables that an application can adjust to 347 control the operation of the User Timeout Option (UTO): ADV_UTO is 348 the value of the UTO advertised to the remote TCP peer (default: 349 system-wide default user timeout); ENABLED (default false) is a 350 boolean-type flag that controls whether the UTO option is enabled 351 for a connection. This applies to both sending and receiving. 352 CHANGEABLE is a boolean-type flag (default true) that controls 353 whether the user timeout may be changed based on a UTO option 354 received from the other end of the connection. CHANGEABLE becomes 355 false when an application explicitly sets the user timeout (see 356 'send'). 358 3.1.1. Excluded Primitives or Parameters 360 The 'open' primitive specified in [RFC0793] can be handed optional 361 Precedence or security/compartment information according to 362 [RFC0793], but this was not included here because it is mostly 363 irrelevant today, as explained in [RFC7414]. 365 The 'status' primitive was not included because [RFC0793] describes 366 this primitive as "implementation dependent" and states that it 367 "could be excluded without adverse effect". Moreover, while a data 368 block containing specific information is described, it is also stated 369 that not all of this information may always be available. While 371 [RFC5925] states that 'status' SHOULD be augmented to allow the MKTs 372 of a current or pending connection to be read (for confirmation), the 373 same information is also available via 'receive', which MUST be 374 augmented with that functionality according to [RFC5925]. The 'send' 375 primitive described in [RFC0793] includes an optional PUSH flag 376 which, if set, requires data to be promptly transmitted to the 377 receiver without delay; the 'receive' primitive described in 378 [RFC0793] can (under some conditions) yield the status of the PUSH 379 flag. Because PUSH functionality is made optional to implement for 380 both the 'send' and 'receive' primitives in [RFC1122], this 381 functionality is not included here. [RFC1122] also introduces keep- 382 alives to TCP, but these are optional to implement and hence not 383 considered here. [RFC1122] describes that "some TCP implementations 384 have included a FLUSH call", indicating that this call is also 385 optional to implement. It is therefore not considered here. 387 3.2. Primitives Provided by MPTCP 389 Multipath TCP (MPTCP) is an extension to TCP that allows the use of 390 multiple paths for a single data-stream. It achieves this by 391 creating different so-called TCP subflows for each of the interfaces 392 and scheduling the traffic across these TCP subflows. The service 393 provided by MPTCP is described in [RFC6182] "Multipath TCP MUST 394 follow the same service model as TCP [RFC0793]: in- order, reliable, 395 and byte-oriented delivery. Furthermore, a Multipath TCP connection 396 SHOULD provide the application with no worse throughput or resilience 397 than it would expect from running a single TCP connection over any 398 one of its available paths." 400 Further, [RFC6182] states constraints on the API exposed by MPTCP: "A 401 multipath-capable equivalent of TCP MUST retain some level of 402 backward compatibility with existing TCP APIs, so that existing 403 applications can use the newer merely by upgrading the operating 404 systems of the end hosts." As such, the primitives provided by MPTCP 405 are equivalent to the ones provided by TCP. Nevertheless, [RFC6824] 406 and [RFC6897] clarify some parts of TCP's primitives with respect to 407 MPTCP and add some extensions for better control on MPTCP's subflows. 408 Hereafter is a list of the clarifications and extensions the above 409 cited RFCs provide to TCP's primitives. 411 open: [RFC6897] states "An application should be able to request to 412 turn on or turn off the usage of MPTCP.". The RFC states that 413 this functionality can be provided through a socket-option called 414 TCP_MULTIPATH_ENABLE. Further, [RFC6897] says that MPTCP must be 415 disabled in case the application is binding to a specific address. 417 send/receive: [RFC6824] states that the sending and receiving of 418 data does not require any changes to the application when MPTCP is 419 being used. The MPTCP-layer will "take one input data stream from 420 an application, and split it into one or more subflows, with 421 sufficient control information to allow it to be reassembled and 422 delivered reliably and in order to the recipient application." 423 The use of the Urgent-Pointer is special in MPTCP and [RFC6824] 424 says "a TCP subflow MUST NOT use the Urgent Pointer to interrupt 425 an existing mapping." 427 address and subflow management: MPTCP uses different addresses and 428 allows a host to announce these addresses as part of the protocol. 429 [RFC6897] says "An application should be able to restrict MPTCP to 430 binding to a given set of addresses." and thus allows applications 431 to limit the set of addresses that are being used by MPTCP. 432 Further, "An application should be able to obtain information on 433 the pairs of addresses used by the MPTCP subflows.". 435 3.3. Primitives Provided by SCTP 437 Section 1.1 of [RFC4960] lists limitations of TCP that SCTP removes. 438 Three of the four mentioned limitations directly translate into 439 Transport Features that are visible to an application using SCTP: 1) 440 it allows for preservation of message delineations; 2) these 441 messages, while reliably transferred, do not require to be in order 442 unless the application wants it; 3) multi-homing is supported. In 443 SCTP, connections are called "associations" and they can be between 444 not only two (as in TCP) but multiple addresses at each endpoint. 446 Section 10 of [RFC4960] further specifies the interaction with the 447 application (which RFC [RFC4960] calls the "Upper Layer Protocol" 448 (ULP)). It is assumed that the Operating System provides a means for 449 SCTP to asynchronously signal the application; the primitives 450 representing such signals are called 'events' in this section. Here, 451 we describe the relevant primitives. In addition to the abstract API 452 described in Section 10 of [RFC4960], an extension to the socket API 453 is described in [RFC6458], covering the functionality of the base 454 protocol specified in [RFC4960] and its extensions specified in 455 [RFC3758], [RFC4895], and [RFC5061]. For the protocol extensions 456 specified in [RFC6525], [RFC6951], [RFC7053], [RFC7496], [RFC7829] 457 and [I-D.ietf-tsvwg-sctp-ndata], the corresponding extensions of the 458 socket API are specified in these protocol specifications. The 459 functionality exposed to the ULP through this socket API is 460 considered here in addition to the abstract API specified in Section 461 10 of [RFC4960]. 463 [RFC4960] contains a "SETPROTOCOLPARAMETERS" primitive that allows to 464 adjust elements of a parameter list; it is stated that SCTP 465 implementations "may allow ULP to customize some of these protocol 466 parameters", indicating that none of the elements of this parameter 467 list are mandatory to make ULP-configurable. Thus, we only consider 468 the parameters in [RFC4960] that are also covered in one of the other 469 RFCs listed above, which leads us to exclude the parameters 470 RTO.Alpha, RTO.Beta and HB.Max.Burst. For clarity, we also replace 471 "SETPROTOCOLPARAMETERS" itself with primitives that adjust parameters 472 or groups of parameters which fit together. 474 Initialize: Initialize, described in [RFC4960], creates a local SCTP 475 instance that it binds to a set of local addresses (and, if 476 provided, port number). Initialize needs to be called only once 477 per set of local addresses. [RFC6458] also describes a number of 478 per-association initialization parameters that can be used when an 479 association is created, but before it is connected (via the 480 primitive 'Associate' below): the maximum number of inbound 481 streams the application is prepared to support, the maximum number 482 of attempts to be made when sending the INIT (the first message of 483 association establishment), and the maximum retransmission timeout 484 (RTO) value to use when attempting an INIT. At this point, before 485 connecting, an application can also enable UDP encapsulation by 486 configuring the remote UDP encapsulation port number [RFC6951]. 488 Associate: This creates an association (the SCTP equivalent of a 489 connection) that connects the local SCTP instance and a remote 490 SCTP instance. To identify the remote endpoint, it can be given 491 one or multiple (using connectx as described in section 9.9 of 492 [RFC6458]) sockets. Most primitives are associated with a 493 specific association, which is assumed to first have been created. 494 Associate can return a list of destination transport addresses so 495 that multiple paths can later be used. One of the returned 496 sockets will be selected by the local endpoint as default primary 497 path for sending SCTP packets to this peer, but this choice can be 498 changed by the application using the list of destination 499 addresses. Associate is also given the number of outgoing streams 500 to request and optionally returns the number of negotiated 501 outgoing streams. An optional parameter of 32 bits, the 502 adaptation layer indication, can be provided, as specified in 503 [RFC5061]. If the extension specified in [RFC4895] is used, the 504 chunk types required to be sent authenticated by the peer can be 505 provided. [RFC6458] describes a 'SCTP_CANT_STR_ASSOC' 506 notification that is used to inform the application of a failure 507 to create an association. [RFC6458] describes how an application 508 could use sendto() or sendmsg() to implicitly setup an 509 association, thereby handing over a message that SCTP might send 510 during the association setup phase. Note that this mechanism is 511 different from TCP's TFO mechanism: the message would arrive only 512 once, after at least one RTT, as it is sent together with the 513 third message exchanged during association setup, the COOKIE-ECHO 514 chunk). 516 Send: This sends a message of a certain length in bytes over an 517 association. A number can be provided to later refer to the 518 correct message when reporting an error, and a stream id is 519 provided to specify the stream to be used inside an association 520 (we consider this as a mandatory parameter here for simplicity: if 521 not provided, the stream id defaults to 0). A condition to 522 abandon the message can be specified (for example limiting the 523 number of retransmissions or the lifetime of the user message). 524 This allows to control the partial reliability extension specified 525 in [RFC3758] and [RFC7496]. An optional maximum life time can 526 specify the time after which the message should be discarded 527 rather than sent. A choice (advisory, i.e. not guaranteed) of the 528 preferred path can be made by providing a socket, and the message 529 can be delivered out-of-order if the unordered flag is set. An 530 advisory flag indicates that the peer should not delay the 531 acknowledgement of the user message provided by making use of the 532 I-bit specified in [RFC7053]. Another advisory flag indicates 533 whether the application prefers to avoid bundling user data with 534 other outbound DATA chunks (i.e., in the same packet). A payload 535 protocol-id can be provided to pass a value that indicates the 536 type of payload protocol data to the peer. If the extension 537 specified in [RFC4895] is used, the key identifier used for 538 authenticating the DATA chunks can be provided. 540 Receive: Messages are received from an association, and optionally a 541 stream within the association, with their size returned. The 542 application is notified of the availability of data via a DATA 543 ARRIVE notification. If the sender has included a payload 544 protocol-id, this value is also returned. If the received message 545 is only a partial delivery of a whole message, a partial flag will 546 indicate so, in which case the stream id and a stream sequence 547 number are provided to the application. A delivery number lets 548 the application detect reordering. 550 Shutdown: This primitive gracefully closes an association, reliably 551 delivering any data that has already been handed over to SCTP. A 552 parameter lets the application control whether further receive or 553 send operations or both are disabled when the call is issued. A 554 return code informs about success or failure of this procedure. 556 Abort: This ungracefully closes an association, by discarding any 557 locally queued data and informing the peer that the association 558 was aborted. Optionally, an abort reason to be passed to the peer 559 may be provided by the application. A return code informs about 560 success or failure of this procedure. 562 Change Heartbeat / Request Heartbeat: This allows the application to 563 enable/disable heartbeats and optionally specify a heartbeat 564 frequency as well as requesting a single heartbeat to be carried 565 out upon a function call, with a notification about success or 566 failure of transmitting the HEARTBEAT chunk to the destination. 568 Configure Max. Retransmissions of an Association: The parameter 569 Association.Max.Retrans in [RFC4960], called sasoc_maxrxt in 570 [RFC6458], allows to configure the number of unsuccessful 571 retransmissions after which an entire association is considered as 572 failed (which should invoke a COMMUNICATION LOST notification). 574 Set Primary: This allows to set a new primary default path for an 575 association by providing a socket. Optionally, a default source 576 address to be used in IP datagrams can be provided. 578 Change Local Address / Set Peer Primary: This allows an endpoint to 579 add/remove local addresses to/from an association. In addition, 580 the peer can be given a hint which address to use as the primary 581 address. This is provided by the protocol extension defined in 582 [RFC5061]. 584 Configure Path Switchover: [RFC4960] contains a primitive called SET 585 FAILURE THRESHOLD. This configures the parameter 586 "Path.Max.Retrans", which determines after how many 587 retransmissions a particular transport address is considered as 588 unreachable. If there are more transport addresses available in 589 an association, reaching this limit will invoke a path switchover. 590 [RFC7829] extends this method with a concept of "Potentially 591 Failed" (PF) paths. When a path is in PF state, SCTP will not 592 entirely give up sending on that path, but it will preferably send 593 data on other active paths if such paths are available. Entering 594 the PF state is done upon exceeding a configured maximum number of 595 retransmissions. Thus, for all paths where this mechanism is 596 used, there are two configurable error thresholds: one to decide 597 that a path is in PF state, and one to decide that the transport 598 address is unreachable. 600 Set / Get Authentication Parameters: This allows an endpoint to add/ 601 remove key material to/from an association. In addition, the 602 chunk types being authenticated can be queried. This is provided 603 by the protocol extension defined in [RFC4895]. 605 Add / Reset Streams, Reset Association: This allows an endpoint to 606 add streams to an existing association or or to reset them 607 individually. Additionally, the association can be reset. This 608 is provided by the protocol extension defined in [RFC6525]. 610 Status: The 'Status' primitive returns a data block with information 611 about a specified association, containing: association connection 612 state; destination transport address list; destination transport 613 address reachability states; current local and peer receiver 614 window sizes; current local congestion window sizes; number of 615 unacknowledged DATA chunks; number of DATA chunks pending receipt; 616 primary path; most recent SRTT on primary path; RTO on primary 617 path; SRTT and RTO on other destination addresses [RFC4960] and 618 MTU per path [RFC6458]. 620 Enable / Disable Interleaving: This allows to enable or disable the 621 negotiation of user message interleaving support for future 622 associations. For existing associations it is possible to query 623 whether user message interleaving support was negotiated or not on 624 a particular association [I-D.ietf-tsvwg-sctp-ndata]. 626 Set Stream Scheduler: This allows to select a stream scheduler per 627 association, with a choice of: First Come First Serve, Round 628 Robin, Round Robin per Packet, Priority Based, Fair Bandwidth, 629 Weighted Fair Queuing. How these schedulers operate is described 630 in detail in [I-D.ietf-tsvwg-sctp-ndata]. 632 Configure Stream Scheduler: This allows to change a parameter per 633 stream for the schedulers: a priority value for the Priority Based 634 scheduler and a weight for the Weighted Fair Queuing scheduler. 636 Enable/disable NODELAY: This turns on/off any Nagle-like algorithm 637 for an association [RFC6458]. 639 Configure send buffer size: This controls the amount of data SCTP 640 may have waiting in internal buffers to be sent or retransmitted 641 [RFC6458]. 643 Configure receive buffer size: This sets the receive buffer size in 644 octets, thereby controlling the receiver window for an association 645 [RFC6458]. 647 Configure message fragmentation: If a user message causes an SCTP 648 packet to exceed the maximum fragmentation size (which can be 649 provided by the application, and is otherwise the PMTU size), then 650 the message will be fragmented by SCTP. Disabling message 651 fragmentation will produce an error instead of fragmenting the 652 message [RFC6458]. 654 Configure Path MTU Discovery: Section 8.1.12 of [RFC6458] explains 655 how Path MTU Discovery can be enabled or disabled per peer address 656 of an association. When it is enabled, the current Path MTU value 657 can be obtained. When it is disabled, the Path MTU to be used can 658 be controlled by the application. 660 Configure delayed SACK timer: The time before sending a SACK can be 661 adjusted; delaying SACKs can be disabled; the number of packets 662 that must be received before a SACK is sent without waiting for 663 the delay timer to expire can be configured [RFC6458]. 665 Set Cookie life value: The Cookie life value can be adjusted as 666 explained in Section 8.1.2 of [RFC6458]. "Valid.Cookie.Life" is 667 also one of the parameters listed as potentially adjustable with 668 SETPROTOCOLPARAMETERS in [RFC4960]. 670 Set maximum burst: The maximum burst of packets that can be emitted 671 by a particular association (default 4, and values above 4 are 672 optional to implement) can be adjusted as explained in Section 673 8.1.2 of [RFC6458]. "Max.Burst" is also one of the parameters 674 listed as potentially adjustable with SETPROTOCOLPARAMETERS in 675 [RFC4960]. 677 Configure RTO calculation: [RFC4960] lists the following adjustable 678 parameters: RTO.Initial; RTO.Min; RTO.Max; RTO.Alpha; RTO.Beta. 679 Only the initial, minimum and maximum RTO are also described as 680 configurable [RFC6458]. 682 Set DSCP value: Section 8.1.12 of [RFC6458] explains how to set the 683 DSCP value per peer address of an association. 685 Set IPv6 flow label: Section 8.1.12 of [RFC6458] explains how to set 686 the flow label field per peer address of an association. 688 Set Partial Delivery Point: This allows to specify the size of a 689 message where partial delivery will be invoked. Setting this to a 690 lower value will cause partial deliveries to happen more often 691 [RFC6458]. 693 COMMUNICATION UP notification: When a lost communication to an 694 endpoint is restored or when SCTP becomes ready to send or receive 695 user messages, this notification informs the application process 696 about the affected association, the type of event that has 697 occurred, the complete set of sockets of the peer, the maximum 698 number of allowed streams and the inbound stream count (the number 699 of streams the peer endpoint has requested). If interleaving is 700 supported by both endpoints, this information is also included in 701 this notification. 703 RESTART notification: When SCTP has detected that the peer has 704 restarted, this notification is passed to the upper layer 705 [RFC6458]. 707 DATA ARRIVE notification: When a message is ready to be retrieved 708 via the Receive primitive, the application is informed by this 709 notification. 711 SEND FAILURE notification / Receive Unsent Message / Receive 712 Unacknowledged Message: When a message cannot be delivered via an 713 association, the sender can be informed about it and learn whether 714 the message has just not been acknowledged or (e.g. in case of 715 lifetime expiry) if it has not even been sent. This can also 716 inform the sender that a part of the message has been successfully 717 delivered. 719 NETWORK STATUS CHANGE notification: The NETWORK STATUS CHANGE 720 notification informs the application about a socket becoming 721 active/inactive [RFC4960] or "Potentially Failed" [RFC7829]. 723 COMMUNICATION LOST notification: When SCTP loses communication to an 724 endpoint (e.g. via Heartbeats or excessive retransmission) or 725 detects an abort, this notification informs the application 726 process of the affected association and the type of event (failure 727 OR termination in response to a shutdown or abort request). 729 SHUTDOWN COMPLETE notification: When SCTP completes the shutdown 730 procedures, this notification is passed to the upper layer, 731 informing it about the affected assocation. 733 AUTHENTICATION notification: When SCTP wants to notify the upper 734 layer regarding the key management related to the extension 735 defined in [RFC4895], this notification is passed to the upper 736 layer. 738 ADAPTATION LAYER INDICATION notification: When SCTP completes the 739 association setup and the peer provided an adaptation layer 740 indication, this is passed to the upper layer. This extension is 741 defined in [RFC5061] and [RFC6458]. 743 STREAM RESET notification: When SCTP completes the procedure for 744 resetting streams as specified in [RFC6525], this notification is 745 passed to the upper layer, informing it about the result. 747 ASSOCIATION RESET notification: When SCTP completes the association 748 reset procedure as specified in [RFC6525], this notification is 749 passed to the upper layer, informing it about the result. 751 STREAM CHANGE notification: When SCTP completes the procedure used 752 to increase the number of streams as specified in [RFC6525], this 753 notification is passed to the upper layer, informing it about the 754 result. 756 SENDER DRY notification: When SCTP has no more user data to send or 757 retransmit on a particular association, this notification is 758 passed to the upper layer [RFC6458]. 760 PARTIAL DELIVERY ABORTED notification: When a receiver has begun to 761 receive parts of a user message but the delivery of this message 762 is then aborted, this notification is passed to the upper layer 763 (section 6.1.7 of [RFC6458]). 765 3.3.1. Excluded Primitives or Parameters 767 The 'Receive' primitive can return certain additional information, 768 but this is optional to implement and therefore not considered. With 769 a COMMUNICATION LOST notification, some more information may 770 optionally be passed to the application (e.g., identification to 771 retrieve unsent and unacknowledged data). SCTP "can invoke" a 772 COMMUNICATION ERROR notification and "may send" a RESTART 773 notification, making these two notifications optional to implement. 774 The list provided under 'Status' includes "etc", indicating that more 775 information could be provided. The primitive 'Get SRTT Report' 776 returns information that is included in the information that 'Status' 777 provides and is therefore not discussed. The 'Destroy SCTP Instance' 778 API function was excluded: it erases the SCTP instance that was 779 created by 'Initialize', but is not a Primitive as defined in this 780 document because it does not relate to a Transport Feature. The 781 SHUTDOWN EVENT described in Section 6.1 of [RFC6458] informs an 782 application that the peer has sent a SHUTDOWN, and hence no further 783 data should be sent on this socket. However, if an application would 784 try to send data on the socket, it would get an error message anyway; 785 thus, this event is classified as "just affecting the application 786 programming style, not how the underlying protocol operates" and not 787 included here. 789 3.4. Primitives Provided by UDP and UDP-Lite 791 The primitives provided by UDP and UDP-Lite are described in [FJ16]. 793 3.5. The service of LEDBAT 795 The service of the Low Extra Delay Background Transport (LEDBAT) 796 congestion control mechanism is described in the abstract of 797 [RFC6817] as follows: "LEDBAT is designed for use by background bulk- 798 transfer applications to be no more aggressive than standard TCP 799 congestion control (as specified in RFC 5681) and to yield in the 800 presence of competing flows, thus limiting interference with the 801 network performance of competing flows." 803 LEDBAT does not have any primitives, as LEDBAT is not a transport 804 protocol. [RFC6817] states: "LEDBAT can be used as part of a 805 transport protocol or as part of an application, as long as the data 806 transmission mechanisms are capable of carrying timestamps and 807 acknowledging data frequently. LEDBAT can be used with TCP, Stream 808 Control Transmission Protocol (SCTP), and Datagram Congestion Control 809 Protocol (DCCP), with appropriate extensions where necessary; and it 810 can be used with proprietary application protocols, such as those 811 built on top of UDP for peer-to- peer (P2P) applications." At the 812 time of writing, the appropriate extensions for TCP, SCTP or DCCP do 813 not exist. 815 A numer of configurable parameters exist in the LEDBAT specification: 816 TARGET, which is the queuing delay target at which LEDBAT tries to 817 operate, must be set to 100ms or less. ALLOWED_INCREASE (should be 818 1, must be greater than 0) limits the speed at which LEDBAT increases 819 its rate. GAIN, which MUST be set to 1 or less to avoid a faster 820 ramp-up than TCP Reno, determines how quickly the sender responds to 821 changes in queueing delay. Implementations may divide GAIN into two 822 parameters, one for increase and a possibly larger one for decrease. 823 We call these parameters GAIN_INC and GAIN_DEC here. BASE_HISTORY is 824 the size of the list of measured base delays, and SHOULD be 10. This 825 list can be filtered using a FILTER() function which is not 826 prescribed in [RFC6817], yielding a list of size CURRENT_FILTER. The 827 initial and minimum congestion windows, INIT_CWND and MIN_CWND, 828 should both be 2. 830 Regarding which of these parameters should be under control of an 831 application, the possible range goes from exposing nothing on the one 832 hand, to considering everything that is not fully prescribed with a 833 MUST in [RFC6817] as a parameter on the other hand. Function 834 implementations are not provided as a parameter to any of the 835 transport protocols discussed here, and hence we do not regard the 836 FILTER() function as a parameter. However, to avoid unnecessarily 837 limiting future implementations, we consider all other parameters 838 above as tunable parameters that should be exposed. 840 4. Pass 2 842 This pass categorizes the primitives from pass 1 based on whether 843 they relate to a connection or to data transmission. Primitives are 844 presented following the nomenclature 845 "CATEGORY.[SUBCATEGORY].PRIMITIVENAME.PROTOCOL". The CATEGORY can be 846 CONNECTION or DATA. Within the CONNECTION category, ESTABLISHMENT, 847 AVAILABILITY, MAINTENANCE and TERMINATION subcategories can be 848 considered. The DATA category does not have any SUBCATEGORY. The 849 PROTOCOL name "UDP(-Lite)" is used when primitives are equivalent for 850 UDP and UDP-Lite; the PROTOCOL name "TCP" refers to both TCP and 851 MPTCP. We present "connection" as a general protocol-independent 852 concept and use it to refer to, e.g., TCP connections (identifiable 853 by a unique pair of IP addresses and TCP port numbers), SCTP 854 associations (identifiable by multiple IP address and port number 855 pairs), as well UDP and UDP-Lite connections (identifiable by a 856 unique socket pair). 858 Some minor details are omitted for the sake of generalization -- 859 e.g., SCTP's 'close' [RFC4960] returns success or failure, and lets 860 the application control whether further receive or send operations or 861 both are disabled [RFC6458]. This is not described in the same way 862 for TCP in [RFC0793], but these details play no significant role for 863 the primitives provided by either TCP or SCTP (for the sake of being 864 generic, it could be assumed that both receive and send operations 865 are disabled in both cases). 867 The TCP 'send' and 'receive' primitives include usage of an "URGENT" 868 mechanism. This mechanism is required to implement the "synch 869 signal" used by telnet [RFC0854], but SHOULD NOT be used by new 870 applications [RFC6093]. Because pass 2 is meant as a basis for the 871 creation of future systems, the "URGENT" mechanism is excluded. This 872 also concerns the notification "Urgent pointer advance" in the 873 ERROR_REPORT described in Section 4.2.4.1 of [RFC1122]. 875 Since LEDBAT is a congestion control mechanism and not a protocol, it 876 is not currently defined when to enable / disable or configure the 877 mechanism. For instance, it could be a one-time choice upon 878 connection establishment or when listening for incoming connections, 879 in which case it should be categorized under CONNECTION.ESTABLISHMENT 880 or CONNECTION.AVAILABILITY, respectively. To avoid unnecessarily 881 limiting future implementations, it was decided to place it under 882 CONNECTION.MAINTENANCE, with all parameters that are described in 883 [RFC6817] made configurable. 885 4.1. CONNECTION Related Primitives 887 ESTABLISHMENT: 888 Active creation of a connection from one transport endpoint to one or 889 more transport endpoints. 890 Interfaces to UDP and UDP-Lite allow both connection-oriented and 891 connection-less usage of the API . [RFC8085] 893 o CONNECT.TCP: 894 Pass 1 primitive / event: 'open' (active) or 'open' (passive) with 895 socket, followed by 'send' 896 Parameters: 1 local IP address (optional); 1 destination transport 897 address (for active open; else the socket and the local IP address 898 of the succeeding incoming connection request will be maintained); 899 timeout (optional); options (optional); MKT configuration 900 (optional); user message (optional) 901 Comments: If the local IP address is not provided, a default 902 choice will automatically be made. The timeout can also be a 903 retransmission count. The options are IP options to be used on 904 all segments of the connection. At least the Source Route option 905 is mandatory for TCP to provide. 'MKT configuration' refers to 906 the ability to configure Master Key Tuples (MKTs) for 907 authentication. The user message may be transmitted to the peer 908 application immediately upon reception of the TCP SYN packet. To 909 benefit from the lower latency this provides as part of the 910 experimental TFO mechanism, its length must be at most the TCP's 911 maximum segment size (minus TCP options used in the SYN). The 912 message may also be delivered more than once to the application on 913 the remote host. 915 o CONNECT.SCTP: 916 Pass 1 primitive / event: 'initialize', followed by 'enable / 917 disable interleaving' (optional), followed by 'associate' 918 Parameters: list of local SCTP port number / IP address pairs 919 (initialize); one or several sockets (identifying the peer); 920 outbound stream count; maximum allowed inbound stream count; 921 adaptation layer indication (optional); chunk types required to be 922 authenticated (optional); request interleaving on/off; maximum 923 number of INIT attemps (optional); maximum init. RTO for INIT 924 (optional); user message (optional); remote UDP port number 925 (optional) 926 Returns: socket list or failure 927 Comments: 'initialize' needs to be called only once per list of 928 local SCTP port number / IP address pairs. One socket will 929 automatically be chosen; it can later be changed in MAINTENANCE. 930 The user message may be transmitted to the peer application 931 immediately upon reception of the packet containing the COOKIE- 932 ECHO chunk. To benefit from the lower latency this provides, its 933 length must be limited such that it fits into the packet 934 containing the COOKIE-ECHO chunk. If a remote UDP port number is 935 provided, SCTP packets will be encapsulated in UDP. 937 o CONNECT.MPTCP: 938 This is similar to CONNECT.TCP except for one additional boolean 939 parameter that allows to enable or disable MPTCP for a particular 940 connection or socket (default: enabled). 942 o CONNECT.UDP(-Lite): 943 Pass 1 primitive / event: 'connect' followed by 'send'. 944 Parameters: 1 local IP address (default (ANY), or specified); 1 945 destination transport address; 1 local port (default (OS chooses), 946 or specified); 1 destination port (default (OS chooses), or 947 specified). 948 Comments: Associates a transport address creating a UDP(-Lite) 949 socket connection. This can be called again with a new transport 950 address to create a new connection. The CONNECT function allows 951 an application to receive errors from messages sent to a transport 952 address. 954 AVAILABILITY: 955 Preparing to receive incoming connection requests. 957 o LISTEN.TCP: 958 Pass 1 primitive / event: 'open' (passive) 959 Parameters: 1 local IP address (optional); 1 socket (optional); 960 timeout (optional); buffer to receive a user message (optional); 961 MKT configuration (optional) 962 Comments: if the socket and/or local IP address is provided, this 963 waits for incoming connections from only and/or to only the 964 provided address. Else this waits for incoming connections 965 without this / these constraint(s). ESTABLISHMENT can later be 966 performed with 'send'. If a buffer is provided to receive a user 967 message, a user message can be received from a TFO-enabled sender 968 before TCP's connection handshake is completed. This message may 969 arrive multiple times. 'MKT configuration' refers to the ability 970 to configure Master Key Tuples (MKTs) for authentication. 972 o LISTEN.SCTP: 973 Pass 1 primitive / event: 'initialize', followed by 'COMMUNICATION 974 UP' or 'RESTART' notification and possibly 'ADAPTATION LAYER' 975 notification 976 Parameters: list of local SCTP port number / IP address pairs 977 (initialize) 978 Returns: socket list; outbound stream count; inbound stream count; 979 adaptation layer indication; chunks required to be authenticated; 980 interleaving supported on both sides yes/no 981 Comments: initialize needs to be called only once per list of 982 local SCTP port number / IP address pairs. COMMUNICATION UP can 983 also follow a COMMUNICATION LOST notification, indicating that the 984 lost communication is restored. If the peer has provided an 985 adaptation layer indication, an 'ADAPTATION LAYER' notification is 986 issued. 988 o LISTEN.MPTCP: 989 This is similar to LISTEN.TCP except for one additional boolean 990 parameter that allows to enable or disable MPTCP for a particular 991 connection or socket (default: enabled). 993 o LISTEN.UDP(-Lite): 994 Pass 1 primitive / event: 'receive'. 995 Parameters: 1 local IP address (default (ANY), or specified); 1 996 destination transport address; local port (default (OS chooses), 997 or specified); destination port (default (OS chooses), or 998 specified). 999 Comments: The receive function registers the application to listen 1000 for incoming UDP(-Lite) datagrams at an endpoint. 1002 MAINTENANCE: 1003 Adjustments made to an open connection, or notifications about it. 1004 These are out-of-band messages to the protocol that can be issued at 1005 any time, at least after a connection has been established and before 1006 it has been terminated (with one exception: CHANGE_TIMEOUT.TCP can 1007 only be issued for an open connection when DATA.SEND.TCP is called). 1008 In some cases, these primitives can also be immediately issued during 1009 ESTABLISHMENT or AVAILABILITY, without waiting for the connection to 1010 be opened (e.g. CHANGE_TIMEOUT.TCP can be done using TCP's 'open' 1011 primitive). For UDP and UDP-Lite, these functions may establish a 1012 setting per connection, but may also be changed per datagram message. 1014 o CHANGE_TIMEOUT.TCP: 1015 Pass 1 primitive / event: 'open' or 'send' combined with 1016 unspecified control of per-connection state variables 1017 Parameters: timeout value (optional); ADV_UTO (optional); boolean 1018 UTO_ENABLED (optional, default false); boolean CHANGEABLE 1019 (optional, default true) 1020 Comments: when sending data, an application can adjust the 1021 connection's timeout value (time after which the connection will 1022 be aborted if data could not be delivered). If UTO_ENABLED is 1023 true, the user timeout value (or, if provided, the value ADV_UTO) 1024 will be advertised for the TCP on the other side of the connection 1025 to adapt its own user timeout accordingly. UTO_ENABLED controls 1026 whether the UTO option is enabled for a connection. This applies 1027 to both sending and receiving. CHANGEABLE controls whether the 1028 user timeout may be changed based on a UTO option received from 1029 the other end of the connection; it becomes false when 'timeout 1030 value' is used. 1032 o CHANGE_TIMEOUT.SCTP: 1033 Pass 1 primitive / event: 'Change HeartBeat' combined with 1034 'Configure Max. Retransmissions of an Association' 1035 Parameters: 'Change HeartBeat': heartbeat frequency; 'Configure 1036 Max. Retransmissions of an Association': Association.Max.Retrans 1037 Comments: Change Heartbeat can enable / disable heartbeats in SCTP 1038 as well as change their frequency. The parameter 1039 Association.Max.Retrans defines after how many unsuccessful 1040 transmissions of any packets (including heartbeats) the 1041 association will be terminated; thus these two primitives / 1042 parameters together can yield a similar behavior for SCTP 1043 associations as CHANGE_TIMEOUT.TCP does for TCP connections. 1045 o DISABLE_NAGLE.TCP: 1046 Pass 1 primitive / event: not specified 1047 Parameters: one boolean value 1048 Comments: the Nagle algorithm delays data transmission to increase 1049 the chance to send a full-sized segment. An application must be 1050 able to disable this algorithm for a connection. 1052 o DISABLE_NAGLE.SCTP: 1053 Pass 1 primitive / event: 'Enable/disable NODELAY' 1054 Parameters: one boolean value 1055 Comments: Nagle-like algorithms delay data transmission to 1056 increase the chance to send a full-sized packet. 1058 o REQUEST_HEARTBEAT.SCTP: 1059 Pass 1 primitive / event: 'Request HeartBeat' 1060 Parameters: socket 1061 Returns: success or failure 1062 Comments: requests an immediate heartbeat on a path, returning 1063 success or failure. 1065 o ADD_PATH.MPTCP: 1066 Pass 1 primitive / event: not specified 1067 Parameters: local IP address and optionally the local port number 1068 Comments: the application specifies the local IP address and port 1069 number that must be used for a new subflow. 1071 o ADD_PATH.SCTP: 1072 Pass 1 primitive / event: Change Local Address / Set Peer Primary 1073 Parameters: local IP address 1075 o REM_PATH.MPTCP: 1076 Pass 1 primitive / event: not specified 1077 Parameters: local IP address, local port number, remote IP 1078 address, remote port number 1079 Comments: the application removes the subflow specified by the IP/ 1080 port-pair. The MPTCP implementation must trigger a removal of the 1081 subflow that belongs to this IP/port-pair. 1083 o REM_PATH.SCTP: 1084 Pass 1 primitive / event: 'Change Local Address / Set Peer 1085 Primary' 1086 Parameters: local IP address 1088 o SET_PRIMARY.SCTP: 1089 Pass 1 primitive / event: 'Set Primary' 1090 Parameters: socket 1091 Returns: result of attempting this operation 1092 Comments: update the current primary address to be used, based on 1093 the set of available sockets of the association. 1095 o SET_PEER_PRIMARY.SCTP: 1096 Pass 1 primitive / event: 'Change Local Address / Set Peer 1097 Primary' 1098 Parameters: local IP address 1099 Comments: this is only advisory for the peer. 1101 o CONFIG_SWITCHOVER.SCTP: 1102 Pass 1 primitive / event: 'Configure Path Switchover' 1103 Parameters: primary max retrans (no. of retransmissions after 1104 which a path is considered inactive), PF max retrans (no. of 1105 retransmissions after which a path is considered to be 1106 "Potentially Failed", and others will be preferably used) 1107 (optional) 1109 o STATUS.SCTP: 1110 Pass 1 primitive / event: 'Status', 'Enable / Disable 1111 Interleaving' and 'NETWORK STATUS CHANGE notification'. 1112 Returns: data block with information about a specified 1113 association, containing: association connection state; destination 1114 transport address list; destination transport address reachability 1115 states; current local and peer receiver window sizes; current 1116 local congestion window sizes; number of unacknowledged DATA 1117 chunks; number of DATA chunks pending receipt; primary path; most 1118 recent SRTT on primary path; RTO on primary path; SRTT and RTO on 1119 other destination addresses; MTU per path; interleaving supported 1120 yes/no. 1121 Comments: The NETWORK STATUS CHANGE notification informs the 1122 application about a socket becoming active/inactive; this only 1123 affects the programming style, as the same information is also 1124 available via 'Status'. 1126 o STATUS.MPTCP: 1127 Pass 1 primitive / event: not specified 1128 Returns: list of pairs of tuples of IP address and TCP port number 1129 of each subflow. The first of the pair is the local IP and port 1130 number, while the second is the remote IP and port number. 1132 o SET_DSCP.TCP: 1133 Pass 1 primitive / event: not specified 1134 Parameters: DSCP value 1135 Comments: this allows an application to change the DSCP value for 1136 outgoing segments. For TCP this was originally specified for the 1137 TOS field [RFC1122], which is here interpreted to refer to the 1138 DSField [RFC3260]. 1140 o SET_DSCP.SCTP: 1141 Pass 1 primitive / event: 'Set DSCP value' 1142 Parameters: DSCP value 1143 Comments: this allows an application to change the DSCP value for 1144 outgoing packets on a path. 1146 o SET_DSCP.UDP(-Lite): 1147 Pass 1 primitive / event: 'SET_DSCP' 1148 Parameter: DSCP value 1149 Comments: This allows an application to change the DSCP value for 1150 outgoing UDP(-Lite) datagrams. [RFC7657] and [RFC8085] provide 1151 current guidance on using this value with UDP. 1153 o ERROR.TCP: 1154 Pass 1 primitive / event: 'ERROR_REPORT' 1155 Returns: reason (encoding not specified); subreason (encoding not 1156 specified) 1157 Comments: soft errors that can be ignored without harm by many 1158 applications; an application should be able to disable these 1159 notifications. The reported conditions include at least: ICMP 1160 error message arrived; Excessive Retransmissions. 1162 o ERROR.UDP(-Lite): 1163 Pass 1 primitive / event: 'ERROR_REPORT'. 1164 Returns: Error report 1165 Comments: This returns soft errors that may be ignored without 1166 harm by many applications; An application must connect to be able 1167 receive these notifications. 1169 o SET_AUTH.TCP: 1170 Pass 1 primitive / event: 'send' 1171 Parameters: current_key, rnext_key 1172 Comments: current_key and rnext_key are the preferred outgoing MKT 1173 and the preferred incoming MKT, respectively, for a segment that 1174 is sent on an active option. 1176 o SET_AUTH.SCTP: 1177 Pass 1 primitive / event: 'Set / Get Authentication Parameters' 1178 Parameters: key_id, key, hmac_id 1180 o GET_AUTH.TCP: 1181 Pass 1 primitive / event: 'receive' 1182 Parameters: current_key, rnext_key 1183 Comments: current_key and rnext_key are the preferred outgoing MKT 1184 and the preferred incoming MKT, respectively, that were carried on 1185 a recently received segment. 1187 o GET_AUTH.SCTP: 1188 Pass 1 primitive / event: 'Set / Get Authentication Parameters' 1189 Parameters: key_id, chunk_list 1191 o RESET_STREAM.SCTP: 1192 Pass 1 primitive / event: 'Add / Reset Streams, Reset Association' 1193 Parameters: sid, direction 1195 o RESET_STREAM-EVENT.SCTP: 1196 Pass 1 primitive / event: 'STREAM RESET notification' 1197 Parameters: information about the result of RESET_STREAM.SCTP. 1198 Comments: This is issued when the procedure for resetting streams 1199 has completed. 1201 o RESET_ASSOC.SCTP: 1202 Pass 1 primitive / event: 'Add / Reset Streams, Reset Association' 1203 Parameters: information related to the extension defined in 1204 [RFC3260]. 1206 o RESET_ASSOC-EVENT.SCTP: 1207 Pass 1 primitive / event: 'ASSOCIATION RESET notification' 1208 Parameters: information about the result of RESET_ASSOC.SCTP. 1209 Comments: This is issued when the procedure for resetting an 1210 association has completed. 1212 o ADD_STREAM.SCTP: 1213 Pass 1 primitive / event: 'Add / Reset Streams, Reset Association' 1214 Parameters: number if outgoing and incoming streams to be added 1216 o ADD_STREAM-EVENT.SCTP: 1217 Pass 1 primitive / event: 'STREAM CHANGE notification' 1218 Parameters: information about the result of ADD_STREAM.SCTP. 1219 Comments: This is issued when the procedure for adding a stream 1220 has completed. 1222 o SET_STREAM_SCHEDULER.SCTP: 1223 Pass 1 primitive / event: 'Set Stream Scheduler' 1224 Parameters: scheduler identifier 1225 Comments: choice of First Come First Serve, Round Robin, Round 1226 Robin per Packet, Priority Based, Fair Bandwidth, Weighted Fair 1227 Queuing. 1229 o CONFIGURE_STREAM_SCHEDULER.SCTP: 1230 Pass 1 primitive / event: 'Configure Stream Scheduler' 1231 Parameters: priority 1232 Comments: the priority value only applies when Priority Based or 1233 Weighted Fair Queuing scheduling is chosen with 1234 SET_STREAM_SCHEDULER.SCTP. The meaning of the parameter differs 1235 between these two schedulers but in both cases it realizes some 1236 form of prioritization regarding how bandwidth is divided among 1237 streams. 1239 o SET_FLOWLABEL.SCTP: 1240 Pass 1 primitive / event: 'Set IPv6 flow label' 1241 Parameters: flow label 1242 Comments: this allows an application to change the IPv6 header's 1243 flow label field for outgoing packets on a path. 1245 o AUTHENTICATION_NOTIFICATION-EVENT.SCTP: 1246 Pass 1 primitive / event: 'AUTHENTICATION notification' 1247 Returns: information regarding key management. 1249 o CONFIG_SEND_BUFFER.SCTP: 1250 Pass 1 primitive / event: 'Configure send buffer size' 1251 Parameters: size value in octets 1253 o CONFIG_RECEIVE_BUFFER.SCTP: 1254 Pass 1 primitive / event: 'Configure receive buffer size' 1255 Parameters: size value in octets 1256 Comments: this controls the receiver window. 1258 o CONFIG_FRAGMENTATION.SCTP: 1259 Pass 1 primitive / event: 'Configure message fragmentation' 1260 Parameters: one boolean value (enable/disable), maximum 1261 fragmentation size (optional; default: PMTU) 1262 Comments: if fragmentation is enabled, messages exceeding the 1263 maximum fragmentation size will be fragmented. If fragmentation 1264 is disabled, trying to send a message that exceeds the maximum 1265 fragmentation size will produce an error. 1267 o CONFIG_PMTUD.SCTP: 1268 Pass 1 primitive / event: 'Configure Path MTU Discovery' 1269 Parameters: one boolean value (PMTUD on/off), PMTU value 1270 (optional) 1271 Returns: PMTU value 1272 Comments: This returns a meaningful PMTU value when PMTUD is 1273 enabled (the boolean is true), and the PMTU value can be set if 1274 PMTUD is disabled (the boolean is false) 1276 o CONFIG_DELAYED_SACK.SCTP: 1277 Pass 1 primitive / event: 'Configure delayed SACK timer' 1278 Parameters: one boolean value (delayed SACK on/off), timer value 1279 (optional), number of packets to wait for (default 2) 1280 Comments: If delayed SACK is enabled, SCTP will send a SACK upon 1281 either receiving the provided number of packets or when the timer 1282 expires, whatever occurs first. 1284 o CONFIG_RTO.SCTP: 1285 Pass 1 primitive / event: 'Configure RTO calculation' 1286 Parameters: init (optional), min (optional), max (optional) 1287 Comments: This adjusts the initial, minimum and maximum RTO 1288 values. 1290 o SET_COOKIE_LIFE.SCTP: 1291 Pass 1 primitive / event: 'Set Cookie life value' 1292 Parameters: cookie life value 1294 o SET_MAX_BURST.SCTP: 1295 Pass 1 primitive / event: 'Set maximum burst' 1296 Parameters: max burst value 1297 Comments: not all implementations allow values above the default 1298 of 4. 1300 o SET_PARTIAL_DELIVERY_POINT.SCTP: 1301 Pass 1 primitive / event: 'Set Partial Delivery Point' 1302 Parameters: partial delivery point (integer) 1303 Comments: this parameter must be smaller or equal to the socket 1304 receive buffer size. 1306 o CHECKSUM.UDP: 1307 Pass 1 primitive / event: 'DISABLE_CHECKSUM'. 1308 Parameters: 0 when no checksum is used at sender, 1 for checksum 1309 at sender (default) 1311 o CHECKSUM_REQUIRED.UDP: 1312 Pass 1 primitive / event: 'REQUIRE_CHECKSUM'. 1313 Parameter: 0 when checksum is required at receiver, 1 to allow 1314 zero checksum at receiver (default) 1316 o SET_CHECKSUM_COVERAGE.UDP-Lite: 1317 Pass 1 primitive / event: 'SET_CHECKSUM_COVERAGE' 1318 Parameters: Coverage length at sender (default maximum coverage) 1320 o SET_MIN_CHECKSUM_COVERAGE.UDP-Lite: 1321 Pass 1 primitive / event: 'SET_MIN_COVERAGE'. 1322 Parameter: Coverage length at receiver (default minimum coverage) 1324 o SET_DF.UDP(-Lite): 1325 Pass 1 primitive event: 'SET_DF'. 1326 Parameter: 0 when DF is not set (default), 1 when DF is set 1328 o SET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS): 1329 Pass 1 primitive / event: 'SET_TTL' and 'SET_IPV6_UNICAST_HOPS' 1330 Parameters: IPv4 TTL value or IPv6 Hop Count value 1331 Comments: This allows an application to change the IPv4 TTL of 1332 IPv6 Hop count value for outgoing UDP(-Lite) datagrams. 1334 o GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS): 1335 Pass 1 primitive / event: 'GET_TTL' and 'GET_IPV6_UNICAST_HOPS' 1336 Returns: IPv4 TTL value or IPv6 Hop Count value 1337 Comments: This allows an application to read the the IPv4 TTL of 1338 IPv6 Hop count value from a received UDP(-Lite) datagram. 1340 o SET_ECN.UDP(-Lite): 1341 Pass 1 primitive / event: 'SET_ECN' 1342 Parameters: ECN value 1343 Comments: This allows a UDP(-Lite) application to set the ECN 1344 codepoint field for outgoing UDP(-Lite) datagrams. 1346 o GET_ECN.UDP(-Lite): 1347 Pass 1 primitive / event: 'GET_ECN' 1348 Parameters: ECN value 1349 Comments: This allows a UDP(-Lite) application to read the ECN 1350 codepoint field from a received UDP(-Lite) datagram. 1352 o SET_IP_OPTIONS.UDP(-Lite): 1353 Pass 1 primitive / event: 'SET_IP_OPTIONS' 1354 Parameters: options 1355 Comments: This allows a UDP(-Lite) application to set IP Options 1356 for outgoing UDP(-Lite) datagrams. These options can at least be 1357 the Source Route, Record Route, and Time Stamp option. 1359 o GET_IP_OPTIONS.UDP(-Lite): 1360 Pass 1 primitive / event: 'GET_IP_OPTIONS' 1361 Returns: options 1362 Comments: This allows a UDP(-Lite) application to receive any IP 1363 options that are contained in a received UDP(-Lite) datagram. 1365 o CONFIGURE.LEDBAT: 1366 Pass 1 primitive / event: N/A 1367 Parameters: enable (boolean), TARGET, ALLOWED_INCREASE, GAIN_INC, 1368 GAIN_DEC, BASE_HISTORY, CURRENT_FILTER, INIT_CWND, MIN_CWND 1369 Comments: enable is a newly invented parameter that enables or 1370 disables the whole LEDBAT service. 1372 TERMINATION: 1373 Gracefully or forcefully closing a connection, or being informed 1374 about this event happening. 1376 o CLOSE.TCP: 1377 Pass 1 primitive / event: 'close' 1378 Comments: this terminates the sending side of a connection after 1379 reliably delivering all remaining data. 1381 o CLOSE.SCTP: 1382 Pass 1 primitive / event: 'Shutdown' 1383 Comments: this terminates a connection after reliably delivering 1384 all remaining data. 1386 o ABORT.TCP: 1387 Pass 1 primitive / event: 'abort' 1388 Comments: this terminates a connection without delivering 1389 remaining data and sends an error message to the other side. 1391 o ABORT.SCTP: 1392 Pass 1 primitive / event: 'abort' 1393 Parameters: abort reason to be given to the peer (optional) 1394 Comments: this terminates a connection without delivering 1395 remaining data and sends an error message to the other side. 1397 o ABORT.UDP(-Lite): 1398 Pass 1 primitive event: 'CLOSE' 1399 Comments: this terminates a connection without delivering 1400 remaining data. No further UDP(-Lite) datagrams are sent/received 1401 on this connection. 1403 o TIMEOUT.TCP: 1404 Pass 1 primitive / event: 'USER TIMEOUT' event 1405 Comments: the application is informed that the connection is 1406 aborted. This event is executed on expiration of the timeout set 1407 in CONNECTION.ESTABLISHMENT.CONNECT.TCP (possibly adjusted in 1408 CONNECTION.MAINTENANCE.CHANGE_TIMEOUT.TCP). 1410 o TIMEOUT.SCTP: 1411 Pass 1 primitive / event: 'COMMUNICATION LOST' event 1412 Comments: the application is informed that the connection is 1413 aborted. this event is executed on expiration of the timeout that 1414 should be enabled by default (see beginning of section 8.3 in 1415 [RFC4960]) and was possibly adjusted in 1416 CONNECTION.MAINTENANCE.CHANGE_TIMEOOUT.SCTP. 1418 o ABORT-EVENT.TCP: 1419 Pass 1 primitive / event: not specified. 1421 o ABORT-EVENT.SCTP: 1422 Pass 1 primitive / event: 'COMMUNICATION LOST' event 1423 Returns: abort reason from the peer (if available) 1424 Comments: the application is informed that the other side has 1425 aborted the connection using CONNECTION.TERMINATION.ABORT.SCTP. 1427 o CLOSE-EVENT.TCP: 1428 Pass 1 primitive / event: not specified. 1430 o CLOSE-EVENT.SCTP: 1431 Pass 1 primitive / event: 'SHUTDOWN COMPLETE' event 1432 Comments: the application is informed that 1433 CONNECTION.TERMINATION.CLOSE.SCTP was successfully completed. 1435 4.2. DATA Transfer Related Primitives 1437 All primitives in this section refer to an existing connection, i.e. 1438 a connection that was either established or made available for 1439 receiving data (although this is optional for the primitives of UDP(- 1440 Lite)). In addition to the listed parameters, all sending primitives 1441 contain a reference to a data block and all receiving primitives 1442 contain a reference to available buffer space for the data. Note 1443 that CONNECT.TCP and LISTEN.TCP in the ESTABLISHMENT and AVAILABILITY 1444 category also allow to transfer data (an optional user message) 1445 before the connection is fully established. 1447 o SEND.TCP: 1448 Pass 1 primitive / event: 'send' 1449 Parameters: timeout (optional), current_key (optional), rnext_key 1450 (optional) 1451 Comments: this gives TCP a data block for reliable transmission to 1452 the TCP on the other side of the connection. The timeout can be 1453 configured with this call (see also 1454 CONNECTION.MAINTENANCE.CHANGE_TIMEOUT.TCP). current_key and 1455 rnext_key are authentication parameters that can be configured 1456 with this call (see also CONNECTION.MAINTENANCE.SET_AUTH.TCP). 1458 o SEND.SCTP: 1459 Pass 1 primitive / event: 'Send' 1460 Parameters: stream number; context (optional); socket (optional); 1461 unordered flag (optional); no-bundle flag (optional); payload 1462 protocol-id (optional); pr-policy (optional) pr-value (optional); 1463 sack-immediately flag (optional); key-id (optional) 1464 Comments: this gives SCTP a data block for transmission to the 1465 SCTP on the other side of the connection (SCTP association). The 1466 'stream number' denotes the stream to be used. The 'context' 1467 number can later be used to refer to the correct message when an 1468 error is reported. The 'socket' can be used to state which path 1469 should be preferred, if there are multiple paths available (see 1470 also CONNECTION.MAINTENANCE.SETPRIMARY.SCTP). The data block can 1471 be delivered out-of-order if the 'unordered flag' is set. The 1472 'no-bundle flag' can be set to indicate a preference to avoid 1473 bundling. The 'payload protocol-id' is a number that will, if 1474 provided, be handed over to the receiving application. Using pr- 1475 policy and pr-value the level of reliability can be controlled. 1476 The 'sack-immediately' flag can be used to indicate that the peer 1477 should not delay the sending of a SACK corresponding to the 1478 provided user message. If specified, the provided key-id is used 1479 for authenticating the user message. 1481 o SEND.UDP(-Lite): 1482 Pass 1 primitive / event: 'SEND' 1483 Parameters: IP Address and Port Number of the destination endpoint 1484 (optional if connected). 1485 Comments: This provides a message for unreliable transmission 1486 using UDP(-Lite) to the specified transport address. IP address 1487 and Port may be omitted for connected UDP(-Lite) sockets. All 1488 CONNECTION.MAINTENANCE.SET_*.UDP(-Lite) primitives apply per 1489 message sent. 1491 o RECEIVE.TCP: 1492 Pass 1 primitive / event: 'receive'. 1493 Parameters: current_key (optional), rnext_key (optional). 1494 Comments: current_key and rnext_key are authentication parameters 1495 that can be read with this call (see also 1496 CONNECTION.MAINTENANCE.GET_AUTH.TCP). 1498 o RECEIVE.SCTP: 1499 Pass 1 primitive / event: 'DATA ARRIVE' notification, followed by 1500 'Receive' 1501 Parameters: stream number (optional) 1502 Returns: stream sequence number (optional), partial flag 1503 (optional) 1504 Comments: if the 'stream number' is provided, the call to receive 1505 only receives data on one particular stream. If a partial message 1506 arrives, this is indicated by the 'partial flag', and then the 1507 'stream sequence number' must be provided such that an application 1508 can restore the correct order of data blocks that comprise an 1509 entire message. Additionally, a delivery number lets the 1510 application detect reordering. 1512 o RECEIVE.UDP(-Lite): 1513 Pass 1 primitive / event: 'RECEIVE', 1514 Parameters: Buffer for received datagram. 1515 Comments: All CONNECTION.MAINTENANCE.GET_*.UDP(-Lite) primitives 1516 apply per message received. 1518 o SENDFAILURE-EVENT.SCTP: 1519 Pass 1 primitive / event: 'SEND FAILURE' notification, optionally 1520 followed by 'Receive Unsent Message' or 'Receive Unacknowledged 1521 Message' 1522 Returns: cause code; context; unsent or unacknowledged message 1523 (optional) 1524 Comments: 'cause code' indicates the reason of the failure, and 1525 'context' is the context number if such a number has been provided 1526 in DATA.SEND.SCTP, for later use with 'Receive Unsent Message' or 1527 'Receive Unacknowledged Message', respectively. These primitives 1528 can be used to retrieve the unsent or unacknowledged message (or 1529 part of the message, in case a part was delivered) if desired. 1531 o SEND_FAILURE.UDP(-Lite): 1532 Pass 1 primitive / event: 'SEND' 1533 Comments: This may be used to probe for the effective PMTU when 1534 using in combination with the 'MAINTENANCE.SET_DF' primitive. 1536 o SENDER_DRY-EVENT.SCTP: 1537 Pass 1 primitive / event: 'SENDER DRY' notification 1538 Comments: This informs the application that the stack has no more 1539 user data to send. 1541 o PARTIAL_DELIVERY_ABORTED-EVENT.SCTP: 1542 Pass 1 primitive / event: 'PARTIAL DELIVERY ABORTED' notification 1543 Comments: This informs the receiver of a partial message that the 1544 further delivery of the message has been aborted. 1546 5. Pass 3 1548 This section presents the superset of all Transport Features in all 1549 protocols that were discussed in the preceding sections, based on the 1550 list of primitives in pass 2 but also on text in pass 1 to include 1551 features that can be configured in one protocol and are static 1552 properties in another (congestion control, for example). Again, some 1553 minor details are omitted for the sake of generalization -- e.g., TCP 1554 may provide various different IP options, but only source route is 1555 mandatory to implement, and this detail is not visible in the Pass 3 1556 feature "Specify IP Options". 1558 5.1. CONNECTION Related Transport Features 1560 ESTABLISHMENT: 1561 Active creation of a connection from one transport endpoint to one or 1562 more transport endpoints. 1564 o Connect 1565 Protocols: TCP, SCTP, UDP(-Lite) 1567 o Specify which IP Options must always be used 1568 Protocols: TCP 1570 o Request multiple streams 1571 Protocols: SCTP 1573 o Limit the number of inbound streams 1574 Protocols: SCTP 1576 o Specify number of attempts and/or timeout for the first 1577 establishment message 1578 Protocols: TCP, SCTP 1580 o Obtain multiple sockets 1581 Protocols: SCTP 1583 o Disable MPTCP 1584 Protocols: MPTCP 1586 o Configure authentication 1587 Protocols: TCP, SCTP 1588 Comments: With TCP, this allows to configure Master Key Tuples 1589 (MKTs). In SCTP, this allows to specify which chunk types must 1590 always be authenticated. DATA, ACK etc. are different 'chunks' in 1591 SCTP; one or more chunks may be included in a single packet. 1593 o Indicate an Adaptation Layer (via an adaptation code point) 1594 Protocols: SCTP 1596 o Request to negotiate interleaving of user messages 1597 Protocols: SCTP 1599 o Hand over a message to transfer (possibly multiple times) before 1600 connection establishment 1601 Protocols: TCP 1603 o Hand over a message to transfer during connection establishment 1604 Protocols: SCTP 1606 o Enable UDP encapsulation with a specified remote UDP port number 1607 Protocols: SCTP 1609 AVAILABILITY: 1610 Preparing to receive incoming connection requests. 1612 o Listen, 1 specified local interface 1613 Protocols: TCP, SCTP, UDP(-Lite) 1615 o Listen, N specified local interfaces 1616 Protocols: SCTP, UDP(-Lite) 1618 o Listen, all local interfaces 1619 Protocols: TCP, SCTP, UDP(-Lite) 1621 o Obtain requested number of streams 1622 Protocols: SCTP 1624 o Limit the number of inbound streams 1625 Protocols: SCTP 1627 o Specify which IP Options must always be used 1628 Protocols: TCP 1630 o Disable MPTCP 1631 Protocols: MPTCP 1633 o Configure authentication 1634 Protocols: TCP, SCTP 1635 Comments: With TCP, this allows to configure Master Key Tuples 1636 (MKTs). In SCTP, this allows to specify which chunk types must 1637 always be authenticated. DATA, ACK etc. are different 'chunks' in 1638 SCTP; one or more chunks may be included in a single packet. 1640 o Indicate an Adaptation Layer (via an adaptation code point) 1641 Protocols: SCTP 1643 MAINTENANCE: 1644 Adjustments made to an open connection, or notifications about it. 1646 o Change timeout for aborting connection (using retransmit limit or 1647 time value) 1648 Protocols: TCP, SCTP 1650 o Suggest timeout to the peer 1651 Protocols: TCP 1653 o Disable Nagle algorithm 1654 Protocols: TCP, SCTP 1656 o Request an immediate heartbeat, returning success/failure 1657 Protocols: SCTP 1659 o Notification of Excessive Retransmissions (early warning below 1660 abortion threshold) 1661 Protocols: TCP 1663 o Add path 1664 Protocols: MPTCP, SCTP 1665 MPTCP Parameters: source-IP; source-Port; destination-IP; 1666 destination-Port 1667 SCTP Parameters: local IP address 1669 o Remove path 1670 Protocols: MPTCP, SCTP 1671 MPTCP Parameters: source-IP; source-Port; destination-IP; 1672 destination-Port 1673 SCTP Parameters: local IP address 1675 o Set primary path 1676 Protocols: SCTP 1678 o Suggest primary path to the peer 1679 Protocols: SCTP 1681 o Configure Path Switchover 1682 Protocols: SCTP 1684 o Obtain status (query or notification) 1685 Protocols: SCTP, MPTCP 1686 SCTP parameters: association connection state; destination 1687 transport address list; destination transport address reachability 1688 states; current local and peer receiver window sizes; current 1689 local congestion window sizes; number of unacknowledged DATA 1690 chunks; number of DATA chunks pending receipt; primary path; most 1691 recent SRTT on primary path; RTO on primary path; SRTT and RTO on 1692 other destination addresses; MTU per path; interleaving supported 1693 yes/no 1694 MPTCP parameters: subflow-list (identified by source-IP; source- 1695 Port; destination-IP; destination-Port) 1697 o Specify DSCP field 1698 Protocols: TCP, SCTP, UDP(-Lite) 1700 o Notification of ICMP error message arrival 1701 Protocols: TCP, UDP(-Lite) 1703 o Change authentication parameters 1704 Protocols: TCP, SCTP 1706 o Obtain authentication information 1707 Protocols: TCP, SCTP 1709 o Reset Stream 1710 Protocols: SCTP 1712 o Notification of Stream Reset 1713 Protocols: STCP 1715 o Reset Association 1716 Protocols: SCTP 1718 o Notification of Association Reset 1719 Protocols: STCP 1721 o Add Streams 1722 Protocols: SCTP 1724 o Notification of Added Stream 1725 Protocols: STCP 1727 o Choose a scheduler to operate between streams of an association 1728 Protocols: SCTP 1730 o Configure priority or weight for a scheduler 1731 Protocols: SCTP 1733 o Specify IPv6 flow label field 1734 Protocols: SCTP 1736 o Configure send buffer size 1737 Protocols: SCTP 1739 o Configure receive buffer (and rwnd) size 1740 Protocols: SCTP 1742 o Configure message fragmentation 1743 Protocols: SCTP 1745 o Configure PMTUD 1746 Protocols: SCTP 1748 o Configure delayed SACK timer 1749 Protocols: SCTP 1751 o Set Cookie life value 1752 Protocols: SCTP 1754 o Set maximum burst 1755 Protocols: SCTP 1757 o Configure size where messages are broken up for partial delivery 1758 Protocols: SCTP 1760 o Disable checksum when sending 1761 Protocols: UDP 1763 o Disable checksum requirement when receiving 1764 Protocols: UDP 1766 o Specify checksum coverage used by the sender 1767 Protocols: UDP-Lite 1769 o Specify minimum checksum coverage required by receiver 1770 Protocols: UDP-Lite 1772 o Specify DF field 1773 Protocols: UDP(-Lite) 1775 o Specify TTL/Hop count field 1776 Protocols: UDP(-Lite) 1778 o Obtain TTL/Hop count field 1779 Protocols: UDP(-Lite) 1781 o Specify ECN field 1782 Protocols: UDP(-Lite) 1784 o Obtain ECN field 1785 Protocols: UDP(-Lite) 1787 o Specify IP Options 1788 Protocols: UDP(-Lite) 1790 o Obtain IP Options 1791 Protocols: UDP(-Lite) 1793 o Enable and configure "Low Extra Delay Background Transfer" 1794 Protocols: A protocol implementing the LEDBAT congestion control 1795 mechanism 1797 TERMINATION: 1798 Gracefully or forcefully closing a connection, or being informed 1799 about this event happening. 1801 o Close after reliably delivering all remaining data, causing an 1802 event informing the application on the other side 1803 Protocols: TCP, SCTP 1804 Comments: A TCP endpoint locally only closes the connection for 1805 sending; it may still receive data afterwards. 1807 o Abort without delivering remaining data, causing an event 1808 informing the application on the other side 1809 Protocols: TCP, SCTP 1810 Comments: In SCTP a reason can optionally be given by the 1811 application on the aborting side, which can then be received by 1812 the application on the other side. 1814 o Abort without delivering remaining data, not causing an event 1815 informing the application on the other side 1816 Protocols: UDP(-Lite) 1818 o Timeout event when data could not be delivered for too long 1819 Protocols: TCP, SCTP 1820 Comments: the timeout is configured with CONNECTION.MAINTENANCE 1821 "Change timeout for aborting connection (using retransmit limit or 1822 time value)". 1824 5.2. DATA Transfer Related Transport Features 1826 All features in this section refer to an existing connection, i.e. a 1827 connection that was either established or made available for 1828 receiving data. Note that TCP allows to transfer data (a single 1829 optional user message, possibly arriving multiple times) before the 1830 connection is fully established. Reliable data transfer entails 1831 delay -- e.g. for the sender to wait until it can transmit data, or 1832 due to retransmission in case of packet loss. 1834 5.2.1. Sending Data 1836 All features in this section are provided by DATA.SEND from pass 2. 1837 DATA.SEND is given a data block from the application, which we here 1838 call a "message" if the beginning and end of the data block can be 1839 identified at the receiver, and "data" otherwise. 1841 o Reliably transfer data, with congestion control 1842 Protocols: TCP 1844 o Reliably transfer a message, with congestion control 1845 Protocols: SCTP 1847 o Unreliably transfer a message, with congestion control 1848 Protocols: SCTP 1850 o Unreliably transfer a message, without congestion control 1851 Protocols: UDP(-Lite) 1853 o Configurable Message Reliability 1854 Protocols: SCTP 1856 o Choice of stream 1857 Protocols: SCTP 1859 o Choice of path (destination address) 1860 Protocols: SCTP 1862 o Choice between unordered (potentially faster) or ordered delivery 1863 of messages 1864 Protocols: SCTP 1866 o Request not to bundle messages 1867 Protocols: SCTP 1869 o Specifying a "payload protocol-id" (handed over as such by the 1870 receiver) 1871 Protocols: SCTP 1873 o Specifying a key id to be used to authenticate a message 1874 Protocols: SCTP 1876 o Request not to delay the acknowledgement (SACK) of a message 1877 Protocols: SCTP 1879 5.2.2. Receiving Data 1881 All features in this section are provided by DATA.RECEIVE from pass 1882 2. DATA.RECEIVE fills a buffer provided by the application, with 1883 what we here call a "message" if the beginning and end of the data 1884 block can be identified at the receiver, and "data" otherwise. 1886 o Receive data (with no message delineation) 1887 Protocols: TCP 1889 o Receive a message 1890 Protocols: SCTP, UDP(-Lite) 1892 o Choice of stream to receive from 1893 Protocols: SCTP 1895 o Information about partial message arrival 1896 Protocols: SCTP 1897 Comments: In SCTP, partial messages are combined with a stream 1898 sequence number so that the application can restore the correct 1899 order of data blocks an entire message consists of. 1901 o Obtain a message delivery number 1902 Protocols: SCTP 1903 Comments: This number can let applications detect and, if desired, 1904 correct reordering. 1906 5.2.3. Errors 1908 This section describes sending failures that are associated with a 1909 specific call to DATA.SEND from pass 2. 1911 o Notification of an unsent (part of a) message 1912 Protocols: SCTP, UDP(-Lite) 1914 o Notification of an unacknowledged (part of a) message 1915 Protocols: SCTP 1917 o Notification that the stack has no more user data to send 1918 Protocols: SCTP 1920 o Notification to a receiver that a partial message delivery has 1921 been aborted 1922 Protocols: SCTP 1924 6. Acknowledgements 1926 The authors would like to thank (in alphabetical order) Bob Briscoe, 1927 David Hayes, Karen Nielsen, Joe Touch and Brian Trammell for 1928 providing valuable feedback on this document. We especially thank 1929 Christoph Paasch for providing input related to Multipath TCP, and 1930 Gorry Fairhurst and Tom Jones for providing input related to UDP(- 1931 Lite), via [FJ16]. This work has received funding from the European 1932 Union's Horizon 2020 research and innovation programme under grant 1933 agreement No. 644334 (NEAT). The views expressed are solely those of 1934 the author(s). 1936 7. IANA Considerations 1938 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 1940 This memo includes no request to IANA. 1942 8. Security Considerations 1944 Authentication, confidentiality protection, and integrity protection 1945 are identified as Transport Features by [RFC8095]. As currently 1946 deployed in the Internet, these features are generally provided by a 1947 protocol or layer on top of the transport protocol; no current full- 1948 featured standards-track transport protocol provides these features 1949 on its own. Therefore, these features are not considered in this 1950 document, with the exception of native authentication capabilities of 1951 TCP and SCTP for which the security considerations in [RFC5925] and 1952 [RFC4895] apply. 1954 9. References 1956 9.1. Normative References 1958 [FJ16] Fairhurst, G. and T. Jones, "Features of the User Datagram 1959 Protocol (UDP) and Lightweight UDP (UDP-Lite) Transport 1960 Protocols", draft-ietf-taps-transports-usage-udp-00 (work 1961 in progress), November 2016. 1963 [I-D.ietf-tsvwg-sctp-ndata] 1964 Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 1965 "Stream Schedulers and User Message Interleaving for the 1966 Stream Control Transmission Protocol", 1967 draft-ietf-tsvwg-sctp-ndata-08 (work in progress), 1968 October 2016. 1970 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1971 RFC 793, DOI 10.17487/RFC0793, September 1981, 1972 . 1974 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1975 Communication Layers", STD 3, RFC 1122, DOI 10.17487/ 1976 RFC1122, October 1989, 1977 . 1979 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 1980 Conrad, "Stream Control Transmission Protocol (SCTP) 1981 Partial Reliability Extension", RFC 3758, DOI 10.17487/ 1982 RFC3758, May 2004, 1983 . 1985 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 1986 "Authenticated Chunks for the Stream Control Transmission 1987 Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, 1988 August 2007, . 1990 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1991 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1992 . 1994 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 1995 Kozuka, "Stream Control Transmission Protocol (SCTP) 1996 Dynamic Address Reconfiguration", RFC 5061, DOI 10.17487/ 1997 RFC5061, September 2007, 1998 . 2000 [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", 2001 RFC 5482, DOI 10.17487/RFC5482, March 2009, 2002 . 2004 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 2005 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 2006 June 2010, . 2008 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 2009 Iyengar, "Architectural Guidelines for Multipath TCP 2010 Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, 2011 . 2013 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 2014 Yasevich, "Sockets API Extensions for the Stream Control 2015 Transmission Protocol (SCTP)", RFC 6458, DOI 10.17487/ 2016 RFC6458, December 2011, 2017 . 2019 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 2020 Transmission Protocol (SCTP) Stream Reconfiguration", 2021 RFC 6525, DOI 10.17487/RFC6525, February 2012, 2022 . 2024 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 2025 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 2026 DOI 10.17487/RFC6817, December 2012, 2027 . 2029 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 2030 "TCP Extensions for Multipath Operation with Multiple 2031 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 2032 . 2034 [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application 2035 Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, 2036 March 2013, . 2038 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 2039 Control Transmission Protocol (SCTP) Packets for End-Host 2040 to End-Host Communication", RFC 6951, DOI 10.17487/ 2041 RFC6951, May 2013, 2042 . 2044 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 2045 IMMEDIATELY Extension for the Stream Control Transmission 2046 Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, 2047 . 2049 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 2050 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 2051 . 2053 [RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, 2054 "Additional Policies for the Partially Reliable Stream 2055 Control Transmission Protocol Extension", RFC 7496, 2056 DOI 10.17487/RFC7496, April 2015, 2057 . 2059 [RFC7829] Nishida, Y., Natarajan, P., Caro, A., Amer, P., and K. 2060 Nielsen, "SCTP-PF: A Quick Failover Algorithm for the 2061 Stream Control Transmission Protocol", RFC 7829, 2062 DOI 10.17487/RFC7829, April 2016, 2063 . 2065 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2066 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2067 March 2017, . 2069 9.2. Informative References 2071 [I-D.draft-gjessing-taps-minset] 2072 Gjessing, S. and M. Welzl, "A Minimal Set of Transport 2073 Services for TAPS Systems", draft-gjessing-taps-minset-04 2074 (work in progress), March 2017. 2076 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 2077 Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, 2078 May 1983, . 2080 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2081 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 2082 RFC2119, March 1997, 2083 . 2085 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2086 of Explicit Congestion Notification (ECN) to IP", 2087 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2088 . 2090 [RFC3260] Grossman, D., "New Terminology and Clarifications for 2091 Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, 2092 . 2094 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 2095 DOI 10.17487/RFC5461, February 2009, 2096 . 2098 [RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the 2099 TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, 2100 January 2011, . 2102 [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. 2103 Zimmermann, "A Roadmap for Transmission Control Protocol 2104 (TCP) Specification Documents", RFC 7414, DOI 10.17487/ 2105 RFC7414, February 2015, 2106 . 2108 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 2109 (Diffserv) and Real-Time Communication", RFC 7657, 2110 DOI 10.17487/RFC7657, November 2015, 2111 . 2113 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 2114 Ed., "Services Provided by IETF Transport Protocols and 2115 Congestion Control Mechanisms", RFC 8095, DOI 10.17487/ 2116 RFC8095, March 2017, 2117 . 2119 Appendix A. Overview of RFCs used as input for pass 1 2121 TCP: [RFC0793], [RFC1122], [RFC5482], [RFC5925], [RFC7413] 2122 MPTCP: [RFC6182], [RFC6824], [RFC6897] 2123 SCTP: RFCs without a socket API specification: [RFC3758], [RFC4895], 2124 [RFC4960], [RFC5061]. 2125 RFCs that include a socket API specification: [RFC6458], 2126 [RFC6525], [RFC6951], [RFC7053], [RFC7496] [RFC7829]. 2127 UDP(-Lite): See [FJ16] 2128 LEDBAT: [RFC6817]. 2130 Appendix B. How this document was developed 2132 This section gives an overview of the method that was used to develop 2133 this document. It was given to contributors for guidance, and it can 2134 be helpful for future updates or extensions. 2136 This document is only concerned with Transport Features that are 2137 explicitly exposed to applications via primitives. It also strictly 2138 follows RFC text: if a feature is truly relevant for an application, 2139 the RFCs should say so, and they should describe how to use and 2140 configure it. Thus, the approach followed for developing this 2141 document was to identify the right RFCs, then analyze and process 2142 their text. 2144 Primitives that MAY be implemented by a transport protocol were 2145 excluded. To be included, the minimum requirement level for a 2146 primitive to be implemented by a protocol was SHOULD. Where 2147 [RFC2119]-style requirements levels are not used, primitives were 2148 excluded when they are described in conjunction with statements like, 2149 e.g.: "some implementations also provide" or "an implementation may 2150 also". Excluded primitives or parameters were briefly described in a 2151 dedicated subsection. 2153 Pass 1: This began by identifying text that talks about primitives. 2154 An API specification, abstract or not, obviously describes primitives 2155 -- but we are not *only* interested in API specifications. The text 2156 describing the 'send' primitive in the API specified in [RFC0793], 2157 for instance, does not say that data transfer is reliable. TCP's 2158 reliability is clear, however, from this text in Section 1 of 2159 [RFC0793]: "The Transmission Control Protocol (TCP) is intended for 2160 use as a highly reliable host-to-host protocol between hosts in 2161 packet-switched computer communication networks, and in 2162 interconnected systems of such networks." 2164 Some text for pass 1 subsections was developed copy+pasting all the 2165 relevant text parts from the relevant RFCs, then adjusting 2166 terminology to match the terminology in Section 1 and adjusting 2167 (shortening!) phrasing to match the general style of the document. 2168 An effort was made to formulate everything as a primitive description 2169 such that the primitive descriptions became as complete as possible 2170 (e.g., the "SEND.TCP" primitive in pass 2 is explicitly described as 2171 reliably transferring data); text that is relevant for the primitives 2172 presented in this pass but still does not fit directly under any 2173 primitive was used in a subsection's introduction. 2175 Pass 2: The main goal of this pass is unification of primitives. As 2176 input, only text from pass 1 was used (no exterior sources). The 2177 list in pass 2 is not arranged by protocol ("first protocol X, here 2178 are all the primitives; then protocol Y, here are all the primitives, 2179 ..") but by primitive ("primitive A, implemented this way in protocol 2180 X, this way in protocol Y, ..."). It was a goal to obtain as many 2181 similar pass 2 primitives as possible. For instance, this was 2182 sometimes achieved by not always maintaining a 1:1 mapping between 2183 pass 1 and pass 2 primitives, renaming primitives etc. For every new 2184 primitive, the already existing primitives were considered to try to 2185 make them as coherent as possible. 2187 For each primitive, the following style was used: 2189 o PRIMITIVENAME.PROTOCOL: 2190 Pass 1 primitive / event: 2191 Parameters: 2192 Returns: 2193 Comments: 2195 The entries "Parameters", "Returns" and "Comments" were skipped when 2196 a primitive had no parameters, no described return value or no 2197 comments seemed necessary, respectively. Optional parameters are 2198 followed by "(optional)". When a default value is known, this was 2199 also provided. 2201 Pass 3: the main point of this pass is to identify transport protocol 2202 features that are the result of static properties of protocols, for 2203 which all protocols have to be listed together; this is then the 2204 final list of all available Transport Features. This list was 2205 primarily based on text from pass 2, with additional input from pass 2206 1 (but no external sources). 2208 Appendix C. Revision information 2210 XXX RFC-Ed please remove this section prior to publication. 2212 -00 (from draft-welzl-taps-transports): this now covers TCP based on 2213 all TCP RFCs (this means: if you know of something in any TCP RFC 2214 that you think should be addressed, please speak up!) as well as 2215 SCTP, exclusively based on [RFC4960]. We decided to also incorporate 2216 [RFC6458] for SCTP, but this hasn't happened yet. Terminology made 2217 in line with [RFC8095]. Addressed comments by Karen Nielsen and 2218 Gorry Fairhurst; various other fixes. Appendices (TCP overview and 2219 how-to-contribute) added. 2221 -01: this now also covers MPTCP based on [RFC6182], [RFC6824] and 2222 [RFC6897]. 2224 -02: included UDP, UDP-Lite, and all extensions of SCTPs. This 2225 includes fixing the [RFC6458] omission from -00. 2227 -03: wrote security considerations. The "how to contribute" section 2228 was updated to reflect how the document WAS created, not how it 2229 SHOULD BE created; it also no longer wrongly says that Experimental 2230 RFCs are excluded. Included LEDBAT. Changed abstract and intro to 2231 reflect which protocols/mechanisms are covered (TCP, MPTCP, SCTP, 2232 UDP, UDP-Lite, LEDBAT) instead of talking about "transport 2233 protocols". Interleaving and stream scheduling added 2234 (draft-ietf-tsvwg-sctp-ndata). TFO added. "Set protocol parameters" 2235 in SCTP replaced with per-parameter (or parameter group) primitives. 2236 More primitives added, mostly previously overlooked ones from 2237 [RFC6458]. Updated terminology (s/transport service feature/ 2238 transport feature) in line with an update of [RFC8095]. Made 2239 sequence of transport features / primitives more logical. Combined 2240 MPTCP's add/rem subflow with SCTP's add/remove local address. 2242 -04: changed UDP's close into an ABORT (to better fit with the 2243 primitives of TCP and SCTP), and incorporated the corresponding 2244 transport feature in step 3 (this addresses a comment from Gorry 2245 Fairhurst). Added TCP Authentication (RFC 5925, section 7.1). 2246 Changed TFO from looking like a primitive in pass 1 to be a part of 2247 'open'. Changed description of SCTP authentication in pass 3 to 2248 encompass both TCP and SCTP. Added citations of [RFC8095] and minset 2249 [I-D.draft-gjessing-taps-minset] to the intro, to give the context of 2250 this document. 2252 Authors' Addresses 2254 Michael Welzl 2255 University of Oslo 2256 PO Box 1080 Blindern 2257 Oslo, N-0316 2258 Norway 2260 Email: michawe@ifi.uio.no 2262 Michael Tuexen 2263 Muenster University of Applied Sciences 2264 Stegerwaldstrasse 39 2265 Steinfurt 48565 2266 Germany 2268 Email: tuexen@fh-muenster.de 2270 Naeem Khademi 2271 University of Oslo 2272 PO Box 1080 Blindern 2273 Oslo, N-0316 2274 Norway 2276 Email: naeemk@ifi.uio.no