idnits 2.17.1 draft-fairhurst-taps-neat-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 13, 2017) is 2349 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-21 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG G. Fairhurst 3 Internet-Draft T. Jones 4 Intended status: Informational University of Aberdeen 5 Expires: May 15, 2018 A. Brunstrom 6 Karlstad University 7 D. Ros 8 Simula Research Laboratory 9 November 13, 2017 11 The NEAT Interface to Transport Services 12 draft-fairhurst-taps-neat-01 14 Abstract 16 The NEAT System provides an example of a system designed to implement 17 the TAPS Transport Services. This document presents the transport 18 services that the NEAT User API provides to an application or upper- 19 layer protocol. It also describes primitives needed to interface to 20 the NEAT Policy Manager and how policies can be adjusted to match the 21 API behaviour to the properties required by an application or upper- 22 layer protocol using the NEAT User API. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 15, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. The NEAT Context . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. NEAT User API Primitives and Events . . . . . . . . . . . . . 5 60 3.1. NEAT Flow Initialisation . . . . . . . . . . . . . . . . . 5 61 3.2. NEAT Flow Establishment . . . . . . . . . . . . . . . . . 6 62 3.3. NEAT Flow Availability . . . . . . . . . . . . . . . . . . 7 63 3.4. Writing and reading data . . . . . . . . . . . . . . . . . 8 64 3.5. Flow Maintenance Primitives . . . . . . . . . . . . . . . 10 65 3.6. NEAT Flow Termination . . . . . . . . . . . . . . . . . . 12 66 3.7. NEAT Error Events . . . . . . . . . . . . . . . . . . . . 12 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 68 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 Appendix A. Revision Information . . . . . . . . . . . . . . . . . 14 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 74 1. Introduction 76 The NEAT (New, Evolutive API and Transport-Layer Architecture for the 77 Internet) [NEAT] System provides a call-back driven API to the 78 network transport layer. It presents a set of transport services 79 [RFC8095] that the NEAT User API provides to an application or upper- 80 layer protocol. 82 The NEAT System has been implemented in the NEAT User Module. The 83 focus of the present document is on the NEAT User API providing 84 transport services to applications. This utilises a lower interface 85 provided by a Kernel Programming Interface (KPI), to access the 86 traditional Socket API or a transport service implemented in 87 userspace. 89 This has been designed to support one-sided deployment, and a NEAT 90 System can therefore exchange data with a variety of transport peers, 91 including: 93 o Another endpoint using the NEAT System 95 o An endpoint using native TCP, UDP, or UDP-Lite. 97 o An endpoint using SCTP (with explicit use of multi-streaming) 99 o WebRTC broswers 100 Applications that use the NEAT User API can provide information about 101 the features desired from the transport layer and determine the 102 properties of the offered transport service. It is this additional 103 information that enables the NEAT System to move beyond the 104 constraints of the traditional Socket API, since the stack then 105 becomes aware of what the application/user actually desires or 106 requires for each traffic flow. The additional information can be 107 used to automatically identify which transport components (protocol 108 and other transport mechanisms) could be used to realise the required 109 transport service. This can drive the selection by the NEAT System 110 of the best transport components to use and determine how these need 111 to be configured [I-D.grinnemo-taps-he]. In making decisions, the 112 NEAT System can utilise policy information provided at configuration, 113 previously discovered path characteristics and probing techniques. 114 This can be provided by a policy manager acting below the NEAT User 115 API. 117 +-------------+ 118 | Application | 119 +-------------+ 120 | /\ Events & Primitives, Set/Get Properties 121 \/ | 122 -+-+-+-+-+-+ Callback-based NEAT User API 123 | /\ 124 \/ | 125 +------------+ Properties +-----------+ +-----------+ 126 | NEAT |----------->| Policy |<----| Policy | 127 | Logic |<-----------| Manager | | Info Base | 128 +------------+ Candidates +-----------+ +-----------+ 129 | | | 130 +-----------+ +-----------+ +-----------+ 131 | Transport | | Transport | | Path Char.| 132 | Protocol | | Protocol | | Info Base | 133 +-----------+ ... +-----------+ +-----------+ 134 | | | 135 ------------------------------------------- 136 | | 137 +-----------+ +-----------+ 138 | Network | | Network | 139 | Interface | | Interface | 140 +-----------+ ... +-----------+ 142 Figure 1: An abstract presentation of the NEAT Architecture and User API. 144 The architecture of the NEAT System is presented in [D1.1], and 145 depicted in Figure 1. Some important features of NEAT compared to the 146 existing Sockets API are: 148 o Event-driven call-back driven interface, enabling applications to 149 be designed to respond to events, such as a signal indictaing 150 reception of data blocks, the ability to send data blocks, or the 151 successful transmission of data blocks. This concrete API is 152 described in [D2.3]. 154 o High-level transport interface, independent of the selected 155 transport protocol, allowing applications to be written without 156 depending on the features of specific transport protocols, and 157 hence allowing the most suitable transport protocol to be matched 158 to the application, based on the transport features an application 159 requires [RFC8095]. 161 o Support for either unordered/unreliable or reliable transport 162 services. 164 o A choice between automatized and explicit support for 165 multistreaming. 167 o Explicit support of multipath transport protocols and network 168 architectures. 170 o A flexible policy framework, allowing applications to describes 171 the properties they expect or those they require of the transport 172 system and thus enabling the transport services to be configured 173 to match the capabilities of the network that is being used. 175 o Ability to work with other network-layer protocols (e.g., network 176 signalling) to realise the required transport service. 178 The NEAT Library is an open source implementation and is available 179 for download [NEAT-GIT]. This also provides tutorials and examples 180 of code utilising the API and descriptions of the way in the which 181 callback mechanisms can be used to build applications that use this 182 interface. Further documentation for the current NEAT System is 183 available at the NEAT Project web page, [NEAT-DOC]. 185 2. The NEAT Context 187 Applications interact with the network by sending, receiving and 188 controlling NEAT Flows. 190 The first step in establishing a flow with the NEAT System is to call 191 a primitive to create and configure a Context. In the remainder of 192 this document, the label P: is used to identify a primitive that may 193 be called for a NEAT Context, and the label E: to identify an event 194 provided by the NEAT System. Each primitive/event is associated with 195 a particular NEAT Context. Most primitives specify the Context and 196 provide a handle to the NEAT Flow upon which they operate, and the 197 primitives and events for manipulating data can only be used after a 198 NEAT Flow has been created. 200 P: INIT_CTX() 202 The INIT_CTX primitive sets up the datastructures needed by the NEAT 203 System. 205 After all network operations are completed it can free the context. 206 It returns a pointer to the newly allocated and initialized NEAT 207 context. 209 P: FREE_CTX() 211 The FREE_CTX primitive is called when an created context is no longer 212 needed. It frees the memory associated with the datastructures used 213 by the NEAT System. 215 3. NEAT User API Primitives and Events 217 An application using the NEAT System needs to take the following 218 steps to use the network after establishing a context: 220 1. Initialisation: create a flow by calling P: INIT_FLOW; and then 221 calling P: SET_PROPERTIES to express the application 222 requirements. This is used by the NEAT policy manager. Finally, 223 it needs to bind call-back functions to respond to the events 224 generated by the NEAT System. 226 2. Establishment / Availability: Connect the NEAT Flow (either 227 actively to a destination endpoint or passively to receive from 228 the network). 230 3. Writing and reading data: Call primitives to write data or 231 respond to events requesting it to read data. 233 4. Maintenance: Call maintenance primitives, as needed, to configure 234 attributes of the flow (e.g., while writing reading data). 236 5. Termination: Close (or abort) the NEAT Flow. 238 3.1. NEAT Flow Initialisation 240 An application needs to create and initialise a flow object before it 241 can be used. 243 P: INIT_FLOW() 245 The INIT_FLOW primitive creates the essential data structures 246 required to use a NEAT Flow. The application also needs to then call 247 a primitive to associate functions with each of the events that it 248 wishes to process. 250 P: SET_PROPERTIES( property_list ) 252 property_list : A set of flow properties expressed in JSON. 254 Each NEAT Flow has a set of properties that are set at the flow 255 initialisation time. The SET_PROPERTIES primitive sets properties 256 for the NEAT Flow. Properties are related to Transport Features and 257 Services. For instance: link-layer security, transport-layer 258 security, certificate verification, certificate and key properties 259 can be set at initialisation time are related to a Confidentiality 260 Transport Feature. A flow can also have attributes that can be read 261 by an application using maintenance primitives after a flow has been 262 initialised. 264 3.2. NEAT Flow Establishment 266 P: OPEN( destname port [stream_count] ) 268 destname : a NEAT-conformant name (which can be a DNS name or a 269 set of IP addresses) to which to connect. 271 port : port number (integer) or service name (string) to which to 272 connect. 274 stream_count : the number of requested streams to open (integer). 275 Note that, if this parameter is not used, the system may still use 276 multi-streaming underneath, e.g., by automatically mapping NEAT 277 Flows between the same hosts onto streams of an SCTP association. 278 Using this parameter disables such automatic functionality. 280 Returns: success or failure. If success, it also returns a handle 281 for a NEAT Flow. 283 The OPEN primitive opens a flow actively for transports that require 284 a connection handshake (e.g., TCP, SCTP), and opens the flow 285 passively for transports that do not (e.g., UDP, UDP-Lite). Calling 286 P:OPEN alone may not actually have an effect "on the wire", i.e., a 287 P: ACCEPT at the peer may not be triggered by it. Since it is 288 possible that the remote endpoint only returns when data arrives, 289 this may only happen after the local host has called P: WRITE. (This 290 does not result in a problem, since P: ACCEPT does not block). 292 E: on_connected 294 The on_connected event indicates a successful connection setup. An 295 application that receives this event can then use other primitives 296 with this flow. 298 P: OPEN_WITH_EARLY_DATA( destname port [stream_count] [flow_group] 299 [stream] [pr_method pr_value] [unordered_flag] data datalen) 301 destname : defined in the same way as in P: OPEN. 303 port : defined in the same way as in P: OPEN. 305 stream_count : defined in the same way as in P: OPEN. 307 flow_group : defined in the same way as in P: OPEN. 309 stream : the number of the stream to be used. At the moment this 310 function is called, a connection is still not initialised and the 311 protocol may not be known. If the protocol chosen by the NEAT 312 Selection components supports only one stream, this parameter will 313 be ignored. 315 pr_method and pr_value : if these parameters are used, then 316 partial reliability is enabled and pr_method must have an integer 317 value from 1 to 2 to specify which method to implement partial 318 reliability is requested. Value 1 means: pr_value specifies a 319 time in milliseconds after which it is unnecessary to send this 320 data block. Value 2 means: pr_value specifies a re- quested 321 maximum number of attempts to retransmit the data block. If the 322 selected NEAT transport does not support partial reliability these 323 parameters will be ignored. (See P: WRITE for more information). 325 unordered_flag : The data block may be delivered out-of-order if 326 this boolean flag is set. Default: false. If the protocol chosen 327 by the NEAT Selection components does not support unordered 328 delivery, this parameter will be ignored. 330 data : the data-block to be sent. 332 datalen : the amount (positive integer) of data supplied in the 333 data-block. 335 Returns: success or failure. If success, it also returns a handle 336 for a NEAT Flow and the amount of supplied data that was buffered. 338 The OPEN_WITH_EARLY_DATA primitive allows data to be sent at the time 339 when a flow is opened. To accommodate TLS 1.3 [I-D.ietf-tls-tls13] 340 early data and the TCP Fast Open option [RFC7413], application data 341 need to be supplied at the time of opening a NEAT Flow. This 342 primitive opens a flow and sends early data if the protocol supports 343 it. If the protocol chosen does not support early application data. 344 The data will be buffered then sent after connection establishment, 345 similar to calling P: WRITE. For this reason, in addition to the 346 parameters of P: OPEN, this primitive also needs the same parameters 347 as P: WRITE. The supplied data can be delivered multiple times 348 (replayed by the network); an application must take this into account 349 when using this function. This is commonly known as idempotence. 351 3.3. NEAT Flow Availability 353 This section describes how an application prepares a flow to accept 354 communication from another NEAT endpoint. 356 P: ACCEPT( [name] port [stream_count] ) 358 name : local NEAT-conformant name (which can be a DNS name or a 359 set of IP addresses) to constrain acceptance of incoming requests 360 to local address(es). If this is missing, requests may arrive at 361 any local address. 363 port : local port number (integer) or service name (string), to 364 constrain acceptance to incoming requests at this port. 366 stream_count : the number of requested streams to open (integer). 367 Default value: 1. 369 Returns: one or more destination IP addresses, information about 370 which destination IP address is used by default, inbound stream 371 count (= the outbound stream count that was requested on the other 372 side), and outbound stream count (= maximum number of allowed 373 outbound streams). 375 The ACCEPT primitive prepares a NEAT Flow to receive network data. 376 UDP and UDP-Lite do not natively support a POSIX-style accept 377 mechanism; in this case, NEAT emulates this functionality. P: ACCEPT 378 can only return once data arrives, not necessarily after the peer has 379 called P: OPEN (The callback-based implementation does not have this 380 problem because P: ACCEPT does not block). 382 E: on_connected 384 The on_connected event indicates a NEAT peer endpoint has connected, 385 and other primitives can then be used. 387 3.4. Writing and reading data 389 The primitives in this section refer to actions that may be performed 390 an open NEAT Flow, i.e., a NEAT Flow that was either actively 391 established or successfully made available for receiving data. It 392 permits an application to send and receive data-blocks over the API. 394 E: on_writable 396 The on_writable event indicates there is buffer space available and 397 the application may write new data using P:WRITE. 399 P: P: WRITE( [stream] [pr_method pr_value] [unordered_flag] data 400 datalen ) 402 stream : the number of the stream to be used (positive integer). 403 This can be omitted if the NEAT Flow contains only one stream. 405 pr_method and pr_value : if these parameters are used, then 406 partial reliability is enabled and pr_method must have an integer 407 value from 1 to 2 to specify which method to implement partial 408 reliability is requested. Value 1 means: pr_value specifies a 409 time in milliseconds after which it is unnecessary to send this 410 data-block. Value 2 means: pr_value specifies a requested maximum 411 number of attempts to retransmit the data-block. If the selected 412 NEAT transport does not support partial reliability these 413 parameters will be ignored 415 unordered_flag : The data block may be delivered out-of-order if 416 this boolean flag is set. Default: false. If the protocol chosen 417 by the NEAT Selection components does not support unordered 418 delivery, this parameter will be ignored. 420 data : The data block to be sent. 422 datalen : the amount (positive integer) of data supplied in data. 424 The WRITE primitive provide a NEAT Flow with a data block for 425 transmission to the remote NEAT peer endpoint (with reliability 426 limited by the conditions specified via pr_method, pr_value and the 427 transport protocol used). NEAT Flows can support message delineation 428 as a property of the NEAT Flow that is set via the INIT_FLOW 429 primitive (S. 2.2.1). If a NEAT Flow supports message delineation, 430 the data block is a complete message. 432 E: on_all_written 434 The on_all_written event indicates that all data requested to be 435 written using P:WRITE has been sent. 437 E: on_send_failure 439 The on_send_failure event may be returned instead of E:on_all_written 440 when the NEAT System was temporarily unable to complete a P:WRITE 441 call, and it not known that all data has been written. 443 E: on_readable 445 The on_readable event indicates there is data available for the 446 application that may be read using P:READ. 448 P: READ( ) 450 data : the received data block. 452 datalen : the amount of data received. 454 Returns: [unordered_flag] [stream_id] data datalen. If a message 455 arrives out of order, this is indicated by the unordered_flag. If 456 the underlying transport protocol supports streams, the stream_id 457 parameter is set. 459 The READ primitive reads a data block from a NEAT Flow into a 460 provided buffer. If a NEAT Flow supports message delineation, the 461 data block is a complete message. 463 3.5. Flow Maintenance Primitives 465 The primitives and events below are out-of-band calls that can be 466 issued at any time after a NEAT Flow has been opened and before it 467 has been terminated. 469 P: CHANGE_TIMEOUT( toval ) 471 toval : the timeout value in seconds. 473 The CHANGE_TIMEOUT primitive adjusts the time after which a NEAT Flow 474 will terminate if the written data could not be delivered. If this 475 is not called, NEAT will make an automatic default choice for the 476 timeout. 478 P: SET_PRIMARY( dst_IP_address ) 480 dst_IP_address : the destination IP address that should be used as 481 the primary address. 483 The SET_PRIMARY primitive is to be used with NEAT Flows that have 484 multiple destination IP addresses, with protocols that do not use 485 load sharing. It should not have an effect otherwise. This will 486 overrule this general per-flow setting. If this is not called, the 487 NEAT System will make an automatic default choice for the destination 488 IP address. 490 P: SET_LOW_WATERMARK( watermark) 492 watermark : upper limit of unsent data in the socket buffer, in 493 bytes. 495 The SET_LOW_WATERMARK primitive allows the application to limit the 496 amount of unsent data in the underlying socket buffer. If set, NEAT 497 will only execute E: WRITABLE when the amount of unsent data falls 498 below the watermark. This allows applications to reduce sender-side 499 queuing delay. 501 P: SET_MIN_CHECKSUM_COVERAGE( length ) 503 length : The number of bytes that must be covered by the checksum 504 for a datagram to be delivered to the application. 506 The SET_MIN_CHECKSUM_COVERAGE primitive allows an application to set 507 the minimum acceptable checksum coverage length. This primitive only 508 has effect for a received UDP-Lite datagram. A receiver that 509 receives a UDP-Lite datagram with a smaller coverage length will not 510 hand over the data to the receiving application. This is ignored for 511 other protocols, where all data are fully covered by the checksum. 513 P: SET_CHECKSUM_COVERAGE( length ) 515 length : sets the number of bytes covered by the checksum on 516 outgoing UDP-Lite datagrams. This is ignored for other protocols, 517 where all data are fully covered by the checksum. 519 The SET_CHECKSUM_COVERAGE primitive allows an application to set the 520 number of bytes covered by the checksum in a UDP-Lite datagram. This 521 only has effect when the UDP-Lite protocol is selected. 523 P: SET_TTL( ttl ) 525 ttl : the hop limit to be used for reception. 527 The SET_TTL primitive sets the minimum IPv4 TTL or IPv6 Hop Count on 528 a datagram that is required for it to be passed to the application. 530 E: on_network_status_changed 532 The on_network_status_changed event informs the application that 533 something has happened in the network; it is safe to ignore without 534 harm by many applications. A status code indicates what has happened 535 in accordance with a table that includes at least the following three 536 values: 1) ICMP error message arrived; 2) Excessive retransmissions; 537 3) one or more destination IP addresses have become available/ 538 unavailable. 540 P: GET_PROPERTY( property ) 542 property : string with a property name, expressed as JSON. 544 Returns: value set to the property returned by the Policy Manager, 545 expressed as JSON. 547 The GET_PROPERTY primitive allows an application to discover the 548 value assigned to a property by the Policy Manager. Properties are 549 expressed as part of policies and handled by the NEAT Policy Manager 550 and can only be read by an application once a flow has been 551 initialised. 553 These currently are: 555 o Transport parameters: Parameters used (e.g., congestion control 556 mechanism, TCP sysctl parameters, . . . ). This property gives the 557 application a more concrete view of the choices that were made. 559 o Interface statistics: Interface MTU, addresses, connection type 560 (link layer), etc. 562 o Path statistics: Experienced RTT, packet loss (rate), jitter, 563 throughput, path MTU, etc 565 o UsedDSCP: The DSCP assigned to an active NEAT Flow. This may 566 differ from the requested DSCP when the QoS has been mapped by the 567 policy system 569 3.6. NEAT Flow Termination 571 This set of primitives and events are related to gracefully or 572 forcefully closing a NEAT Flow, or being informed about this 573 happening. 575 P: CLOSE( ) 577 The CLOSE primitive terminates a NEAT Flow after satisfying all the 578 requirements that were specified regarding the delivery of data that 579 the application has already given to NEAT. If the peer still has data 580 to send, it cannot then be received after this call. Data buffered 581 by the NEAT System that has not yet been given to the network layer 582 will be discarded. 584 E: on_close 586 The on_close event informs the application that a NEAT Flow was 587 successfully closed. This can be received at any time for an active 588 NEAT Flow. 590 P: ABORT( ) 592 The ABORT primitive terminates a connection without delivering 593 remaining data. 595 E: on_aborted 597 The on_aborted event informs the application that the other side has 598 aborted the NEAT Flow. The event can be received at any time for an 599 active NEAT Flow. 601 E: on_timeout 603 The on_timeout event informs the application that the NEAT Flow is 604 aborted because the default timeout has been reached before data 605 could be delivered. This timeout adjusted by the P: CHANGE_TIMEOUT 606 NEAT Flow maintenance primitive. The event can be received at any 607 time for an active NEAT Flow. 609 3.7. NEAT Error Events 610 Errors that occur within the NEAT System or that are notified by the 611 network result in an on_error event: 613 E: on_error 615 This event notifies a hard or soft error to the upper layer using the 616 NEAT System. 618 4. Security Considerations 620 This document is about the design and usage of a transport API. The 621 transport protocols accessed via this API each have security 622 considerations. 624 The API may be used to request the use of security protocols accessed 625 via the transport API. 627 5. Acknowledgements 629 This work was partially funded by the European Union's Horizon 2020 630 research and innovation programme under grant agreement No. 644334 631 (NEAT). The views expressed are solely those of the author(s). 633 6. IANA Considerations 635 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 637 This memo includes no request to IANA. 639 7. References 641 [D1.1] Fairhurst, G., Jones, T., Damjanovic, D., Eckert, K., 642 Grinnemo, K., Hansen, A., Mangiante, S., McManus, P., 643 Papastergiou, G., Ros, D., Vyncke, E., Welzl, M. and M. 644 Tuexen, "The NEAT Architecture (D1.1)", 2015, . 647 [D2.3] Khademi, N., Bozakov, Z., Brunstroem, A., Dale, O., 648 Damjanovic, D., Evensen, KR., Fairhurst, G., Fischer, A., 649 Grinnemo, K., Jones, T., Mangiante, S., Petlund, A., Ros, 650 D., Ruengeler, I., Stenberg, D., Tuexen, M., Weinrank, F. 651 and M. Welzl, "The Final Version of Core Transport System 652 (D2.3)", 2017, . 655 [I-D.grinnemo-taps-he] 656 Grinnemo, K., Brunstrom, A., Hurtig, P., Khademi, N. and 657 Z. Bozakov, "Happy Eyeballs for Transport Selection", 658 Internet-Draft draft-grinnemo-taps-he-03, July 2017. 660 [I-D.ietf-tls-tls13] 661 Rescorla, E., "The Transport Layer Security (TLS) Protocol 662 Version 1.3", Internet-Draft draft-ietf-tls-tls13-21, July 663 2017. 665 [NEAT-DOC] 666 Stenberg, D., Weinrank, F., Khademi, N., Dreibholz, T., 667 Jones, T., Bozakov, Z. and O. Dale, "NEAT Programming API 668 Documentation", , . 670 [NEAT-GIT] 671 "NEAT Source Code Repository", , . 674 [NEAT] "The EU New, Evolutive API and Transport-Layer 675 Architecture for the Internet (NEAT) Project", 2017, 676 . 678 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S. and A. Jain, "TCP 679 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 680 . 682 [RFC8095] Fairhurst, G., Ed., Trammell, B.Ed., and M. Kuehlewind, 683 Ed., "Services Provided by IETF Transport Protocols and 684 Congestion Control Mechanisms", RFC 8095, DOI 10.17487/ 685 RFC8095, March 2017, . 688 Appendix A. Revision Information 690 -00 This is an individual draft for the IETF community, for 691 consideration by the IETF TAPS WG. 693 -01 Contains corrections to INIT_FLOW; fixes to typos; and includes 694 the Acknolwkedgment text omitted by mistake in -00. 696 Authors' Addresses 698 Godred Fairhurst 699 University of Aberdeen 700 Department of Engineering 701 Fraser Noble Building 702 Aberdeen, AB24 3UE 703 Scotland 705 Email: gorry@erg.abdn.ac.uk 706 URI: http://www.erg.abdn.ac.uk/ 707 Tom Jones 708 University of Aberdeen 709 Department of Engineering 710 Fraser Noble Building 711 Aberdeen, AB24 3UE 712 Scotland 714 Email: tom@erg.abdn.ac.uk 715 URI: http://www.erg.abdn.ac.uk/ 717 Anna Brunstrom 718 Karlstad University 719 Universitetsgatan 2 720 Karlstad, 651 88 721 Sweden 723 Email: anna.brunstrom@kau.se 725 David Ros 726 Simula Research Laboratory 727 Martin Linges vei 25 728 1364 Fornebu 729 Oslo, 730 Norway 732 Email: dros@simula.no