idnits 2.17.1 draft-fairhurst-taps-neat-00.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2370 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: 1 error (**), 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 01, 2018 A. Brunstrom 6 Karlstad University 7 D. Ros 8 Simula Research Laboratory 9 October 30, 2017 11 The NEAT Interface to Transport Services 12 draft-fairhurst-taps-neat-00 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 01, 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 . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. NEAT User API Primitives and Events . . . . . . . . . . . . . 4 60 3.1. NEAT Flow Initialisation . . . . . . . . . . . . . . . . . 4 61 3.2. NEAT Flow Establishment . . . . . . . . . . . . . . . . . 5 62 3.3. NEAT Flow Availability . . . . . . . . . . . . . . . . . . 7 63 3.4. Writing and reading data . . . . . . . . . . . . . . . . . 7 64 3.5. Flow Maintenance Primitives . . . . . . . . . . . . . . . 9 65 3.6. NEAT Flow Termination . . . . . . . . . . . . . . . . . . 11 66 3.7. NEAT Error Events . . . . . . . . . . . . . . . . . . . . 12 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 Appendix A. Revision Information . . . . . . . . . . . . . . . . . 13 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 The NEAT (New, Evolutive API and Transport-Layer Architecture for the 76 Internet) [NEAT] System provides a call-back driven API to the 77 network transport layer. It presents a set of transport services 78 [RFC8095] that the NEAT User API provides to an application or upper- 79 layer protocol. 81 The NEAT System has been implemented in the NEAT User Module. The 82 focus of the present document is on the NEAT User API providing 83 transport services to applications. This utilises a lower interface 84 provided by a Kernel Programming Interface (KPI), to access the 85 traditional Socket API or a transport service implemented in 86 userspace. 88 Applications that use the NEAT User API can provide information about 89 the features desired from the transport layer and determine the 90 properties of the offered transport service. It is this additional 91 information that enables the NEAT System to move beyond the 92 constraints of the traditional Socket API, since the stack then 93 becomes aware of what the application/user actually desires or 94 requires for each traffic flow. The additional information can be 95 used to automatically identify which transport components (protocol 96 and other transport mechanisms) could be used to realise the required 97 transport service. This can drive the selection by the NEAT System 98 of the best transport components to use and determine how these need 99 to be configured [I-D.grinnemo-taps-he]. In making decisions, the 100 NEAT System can utilise policy information provided at configuration, 101 previously discovered path characteristics and probing techniques. 102 This can be provided by a policy manager acting below the NEAT User 103 API. 105 The architecture of the NEAT System is presented in [D1.1]. Some 106 important features of NEAT compared to the existing sockets API are: 108 o Event-driven call-back driven interface, enabling applications to 109 be designed so that they respond to events signalling the 110 reception of data blocks, ability to send data blocks, or the 111 successful transmission of data blocks. This concrete API is 112 described in [D2.3]. 114 o High-level transport interface independent of the selected 115 transport protocol, allowing applications to be written without 116 depending on the features of specific transport protocols, and 117 hence allowing the most suitable transport protocol to be matched 118 to the application, based on the transport features an application 119 requires [RFC8095]. 121 o Support for unordered/unreliable and reliable transport services. 123 o Explicit support for multistreaming and multipath transport 124 protocols and network architectures. 126 o A flexible policy framework, allowing applications to describes 127 the properties they expect or require of the transport system and 128 thus enabling the transport services to be configured to match the 129 capabilities of the network that is being used. 131 o Ability to work with other network-layer protocols (e.g., network 132 signalling) to realise the required transport service. 134 The NEAT Library is an open source implementation and is available 135 for download [NEAT-GIT]. This also provides tutorials and examples 136 of code utilising the API and descriptions of the way in the which 137 callback mechanisms can be used to build applications that use this 138 interface. Further documentation for the current NEAT System is 139 available at the NEAT Project web page, [NEAT-DOC]. 141 2. The NEAT Context 143 Applications interact with the network by sending, receiving and 144 controlling NEAT Flows. 146 The first step in establishing a flow with the NEAT System is to call 147 a primitive to create and configure a Context. In the remainder of 148 this document, the label P: is used to identify a primitive that may 149 be called for a NEAT Context, and the label E: to identify an event 150 provided by the NEAT System. Each primitive/event is associated with 151 a particular NEAT Context. Most primitives specify the Context and 152 provide a handle to the NEAT Flow upon which they operate, and the 153 primitives and events for manipulating data can only be used after a 154 NEAT Flow has been created. 156 P: INIT_CTX() 158 The INIT_CTX primitive sets up the datastructures needed by the NEAT 159 System. 161 After all network operations are completed it can free the context. 162 It returns a pointer to the newly allocated and initialized NEAT 163 context. 165 P: FREE_CTX() 167 The FREE_CTX primitive is called when an created context is no longer 168 needed. It frees the memory associated with the datastructures used 169 by the NEAT System. 171 3. NEAT User API Primitives and Events 173 An application using the NEAT System needs to take the following 174 steps to use the network after establishing a context: 176 1. Initialisation: create a flow by calling P: INIT_FLOW; and then 177 calling P: SET_PROPERTIES to express the application 178 requirements. This is used by the NEAT policy manager. Finally, 179 it needs to bind call-back functions to respond to the events 180 generated by the NEAT System. 182 2. Establishment / Availability: Connect the NEAT Flow (either 183 actively to a destination endpoint or passively to receive from 184 the network). 186 3. Writing and reading data: Call primitives to write data or 187 respond to events requesting it to read data. 189 4. Maintenance: Call maintenance primitives, as needed, to configure 190 attributes of the flow (e.g., while writing reading data). 192 5. Termination: Close (or abort) the NEAT Flow. 194 3.1. NEAT Flow Initialisation 196 An application needs to create and initialise a flow object before it 197 can be used. 199 P: INIT_FLOW() 201 The INIT_FLOW primitive creates the essential data structures 202 required to use a NEAT Flow. The application also needs to then call 203 a primitive associate functions with each of the events that it 204 wishes to process. 206 P: SET_PROPERTIES( property_list ) 208 property_list : A set of flow properties expressed in JSON. 210 Each NEAT Flow has a set of properties that are set at the flow 211 initialisation time. The SET_PROPERTIES primitive sets properties 212 for the NEAT Flow. Properties are related to Transport Features and 213 Services. For instance: link-layer security, transport-layer 214 security, certificate verification, certificate and key properties 215 can be set at initialisation time are related to a Confidentiality 216 Transport Feature. A flow can also have attributes that can be read 217 by an application using maintenance primitives after a flow has been 218 initialised. 220 3.2. NEAT Flow Establishment 222 P: OPEN( destname port [stream_count] ) 224 destname : a NEAT-conformant name (which can be a DNS name or a 225 set of IP addresses) to which to connect. 227 port : port number (integer) or service name (string) to which to 228 connect. 230 stream_count : the number of requested streams to open (integer). 231 Note that, if this parameter is not used, the system may still use 232 multi-streaming underneath, e.g., by automatically mapping NEAT 233 Flows between the same hosts onto streams of an SCTP association. 234 Using this parameter disables such automatic functionality. 236 Returns: success or failure. If success, it also returns a handle 237 for a NEAT Flow. 239 The OPEN primitive opens a flow actively for transports that require 240 a connection handshake (e.g., TCP, SCTP), and opens the flow 241 passively for transports that do not (e.g., UDP, UDP-Lite). Calling 242 P:OPEN alone may not actually have an effect "on the wire", i.e., a 243 P: ACCEPT at the peer may not be triggered by it. Since it is 244 possible that the remote endpoint only returns when data arrives, 245 this may only happen after the local host has called P: WRITE. (This 246 does not result in a problem, since P: ACCEPT does not block). 248 E: on_connected 250 The on_connected event indicates a successful connection setup. An 251 application that receives this event can then use other primitives 252 with this flow. 254 P: OPEN_WITH_EARLY_DATA( destname port [stream_count] [flow_group] 255 [stream] [pr_method pr_value] [unordered_flag] data datalen) 257 destname : defined in the same way as in P: OPEN. 259 port : defined in the same way as in P: OPEN. 261 stream_count : defined in the same way as in P: OPEN. 263 flow_group : defined in the same way as in P: OPEN. 265 stream : the number of the stream to be used. At the moment this 266 function is called, a connection is still not initialised and the 267 protocol may not be known. If the protocol chosen by the NEAT 268 Selection components supports only one stream, this parameter will 269 be ignored. 271 pr_method and pr_value : if these parameters are used, then 272 partial reliability is enabled and pr_method must have an integer 273 value from 1 to 2 to specify which method to implement partial 274 reliability is requested. Value 1 means: pr_value specifies a 275 time in milliseconds after which it is unnecessary to send this 276 data block. Value 2 means: pr_value specifies a re- quested 277 maximum number of attempts to retransmit the data block. If the 278 selected NEAT transport does not support partial reliability these 279 parameters will be ignored. (See P: WRITE for more information). 281 unordered_flag : The data block may be delivered out-of-order if 282 this boolean flag is set. Default: false. If the protocol chosen 283 by the NEAT Selection components does not support unordered 284 delivery, this parameter will be ignored. 286 data : the data-block to be sent. 288 datalen : the amount (positive integer) of data supplied in the 289 data-block. 291 Returns: success or failure. If success, it also returns a handle 292 for a NEAT Flow and the amount of supplied data that was buffered. 294 The OPEN_WITH_EARLY_DATA primitive allows data to be sent at the time 295 when a flow is opened. To accommodate TLS 1.3 [I-D.ietf-tls-tls13] 296 early data and the TCP Fast Open option [RFC7413], application data 297 need to be supplied at the time of opening a NEAT Flow. This 298 primitive opens a flow and sends early data if the protocol supports 299 it. If the protocol chosen does not support early application data. 300 The data will be buffered then sent after connection establishment, 301 similar to calling P: WRITE. For this reason, in addition to the 302 parameters of P: OPEN, this primitive also needs the same parameters 303 as P: WRITE. The supplied data can be delivered multiple times 304 (replayed by the network); an application must take this into account 305 when using this function. This is commonly known as idempotence. 307 3.3. NEAT Flow Availability 309 This section describes how an application prepares a flow to accept 310 communication from another NEAT endpoint. 312 P: ACCEPT( [name] port [stream_count] ) 314 name : local NEAT-conformant name (which can be a DNS name or a 315 set of IP addresses) to constrain acceptance of incoming requests 316 to local address(es). If this is missing, requests may arrive at 317 any local address. 319 port : local port number (integer) or service name (string), to 320 constrain acceptance to incoming requests at this port. 322 stream_count : the number of requested streams to open (integer). 323 Default value: 1. 325 Returns: one or more destination IP addresses, information about 326 which destination IP address is used by default, inbound stream 327 count (= the outbound stream count that was requested on the other 328 side), and outbound stream count (= maximum number of allowed 329 outbound streams). 331 The ACCEPT primitive prepares a NEAT Flow to receive network data. 332 UDP and UDP-Lite do not natively support a POSIX-style accept 333 mechanism; in this case, NEAT emulates this functionality. P: ACCEPT 334 can only return once data arrives, not necessarily after the peer has 335 called P: OPEN (The callback-based implementation does not have this 336 problem because P: ACCEPT does not block). 338 E: on_connected 340 The on_connected event indicates a NEAT peer endpoint has connected, 341 and other primitives can then be used. 343 3.4. Writing and reading data 344 The primitives in this section refer to actions that may be performed 345 an open NEAT Flow, i.e., a NEAT Flow that was either actively 346 established or successfully made available for receiving data. It 347 permits an application to send and receive data-blocks over the API. 349 E: on_writable 351 The on_writable event indicates there is buffer space available and 352 the application may write new data using P:WRITE. 354 P: P: WRITE( [stream] [pr_method pr_value] [unordered_flag] data 355 datalen ) 357 stream : the number of the stream to be used (positive integer). 358 This can be omitted if the NEAT Flow contains only one stream. 360 pr_method and pr_value : if these parameters are used, then 361 partial reliability is enabled and pr_method must have an integer 362 value from 1 to 2 to specify which method to implement partial 363 reliability is requested. Value 1 means: pr_value specifies a 364 time in milliseconds after which it is unnecessary to send this 365 data-block. Value 2 means: pr_value specifies a requested maximum 366 number of attempts to retransmit the data-block. If the selected 367 NEAT transport does not support partial reliability these 368 parameters will be ignored 370 unordered_flag : The data block may be delivered out-of-order if 371 this boolean flag is set. Default: false. If the protocol chosen 372 by the NEAT Selection components does not support unordered 373 delivery, this parameter will be ignored. 375 data : The data block to be sent. 377 datalen : the amount (positive integer) of data supplied in data. 379 The WRITE primitive provide a NEAT Flow with a data block for 380 transmission to the remote NEAT peer endpoint (with reliability 381 limited by the conditions specified via pr_method, pr_value and the 382 transport protocol used). NEAT Flows can support message delineation 383 as a property of the NEAT Flow that is set via the INIT_FLOW 384 primitive (S. 2.2.1). If a NEAT Flow supports message delineation, 385 the data block is a complete message. 387 E: on_all_written 389 The on_all_written event indicates that all data requested to be 390 written using P:WRITE has been sent. 392 E: on_send_failure 394 The on_send_failure event may be returned instead of E:on_all_written 395 when the NEAT System was temporarily unable to complete a P:WRITE 396 call, and it not known that all data has been written. 398 E: on_readable 400 The on_readable event indicates there is data available for the 401 application that may be read using P:READ. 403 P: READ( ) 405 data : the received data block. 407 datalen : the amount of data received. 409 Returns: [unordered_flag] [stream_id] data datalen If a message 410 arrives out of order, this is indicated by unordered_flag. If the 411 underlying transport protocol supports streams, the stream_id 412 parameter is set. 414 The READ primitive reads a data block from a NEAT Flow into a 415 provided buffer. NEAT Flows can support message delineation as a 416 property of the NEAT Flow that is set via the INIT_FLOW primitive. 417 If a NEAT Flow supports message delineation, the data block is a 418 complete message. 420 3.5. Flow Maintenance Primitives 422 The primitives and events below are out-of-band calls that can be 423 issued at any time after a NEAT Flow has been opened and before it 424 has been terminated. 426 P: CHANGE_TIMEOUT( toval ) 428 toval : the timeout value in seconds. 430 The CHANGE_TIMEOUT primitive adjusts the time after which a NEAT Flow 431 will terminate if the written data could not be delivered. If this 432 is not called, NEAT will make an automatic default choice for the 433 timeout. 435 P: SET_PRIMARY( dst_IP_address ) 437 dst_IP_address : the destination IP address that should be used as 438 the primary address. 440 The SET_PRIMARY primitive is to be used with NEAT Flows that have 441 multiple destination IP addresses, with protocols that do not use 442 load sharing. It should not have an effect otherwise. This will 443 overrule this general per-flow setting. If this is not called, the 444 NEAT System will make an automatic default choice for the destination 445 IP address. 447 P: SET_LOW_WATERMARK( watermark) 448 watermark : upper limit of unsent data in the socket buffer, in 449 bytes. 451 The SET_LOW_WATERMARK primitive allows the application to limit the 452 amount of unsent data in the underlying socket buffer. If set, NEAT 453 will only execute E: WRITABLE when the amount of unsent data falls 454 below the watermark. This allows applications to reduce sender-side 455 queuing delay. 457 P: SET_MIN_CHECKSUM_COVERAGE( length ) 459 length : The number of bytes that must be covered by the checksum 460 for a datagram to be delivered to the application. 462 The SET_MIN_CHECKSUM_COVERAGE primitive allows an application to set 463 the minimum acceptable checksum coverage length. This primitive only 464 has effect for a received UDP-Lite datagram. A receiver that 465 receives a UDP-Lite datagram with a smaller coverage length will not 466 hand over the data to the receiving application. This is ignored for 467 other protocols, where all data are fully covered by the checksum. 469 P: SET_CHECKSUM_COVERAGE( length ) 471 length : sets the number of bytes covered by the checksum on 472 outgoing UDP-Lite datagrams. This is ignored for other protocols, 473 where all data are fully covered by the checksum. 475 The SET_CHECKSUM_COVERAGE primitive allows an application to set the 476 number of bytes covered by the checksum in a UDP-Lite datagram. This 477 only has effect when the UDP-Lite protocol is selected. 479 P: SET_TTL( ttl ) 481 ttl : the hop limit to be used for reception. 483 The SET_TTL primitive sets the minimum IPv4 TTL or IPv6 Hop Count on 484 a datagram that is required for it to be passed to the application. 486 E: on_network_status_changed 488 The on_network_status_changed event informs the application that 489 something has happened in the network; it is safe to ignore without 490 harm by many applications. A status code indicates what has happened 491 in accordance with a table that includes at least the following three 492 values: 1) ICMP error message arrived; 2) Excessive retransmissions; 493 3) one or more destination IP addresses have become available/ 494 unavailable. 496 P: GET_PROPERTY( property ) 498 property : string with a property name. 500 Returns: value set to the property by the Policy Manager expressed 501 as JSON. 503 The GET_PROPERTY primitive allows an application to discover the 504 value assigned to a property by the Policy Manager. Properties are 505 expressed as part of policies and handled by the NEAT Policy Manager 506 and can only be read by an application once a flow has been 507 initialised. 509 These currently are: 511 o Transport parameters: Parameters used (e.g., congestion control 512 mechanism, TCP sysctl parameters, . . . ). For example, the choice 513 of congestion control mechanism is likely to depend on the 514 capacity_profile parameter of the INIT_FLOW primitive, if that 515 parameter is used -\u002D but does not specify a concrete 516 congestion control algorithm, which this read- able property 517 returns. More generally, this property gives the application a 518 more concrete view of the choices made by the NEAT System. 520 o Interface statistics: Interface MTU, addresses, connection type 521 (link layer), etc. 523 o Path statistics: Experienced RTT, packet loss (rate), jitter, 524 throughput, path MTU, etc 526 o UsedDSCP: The DSCP assigned to an active NEAT Flow. This may 527 differ from the requested DSCP when the QoS has been mapped by the 528 policy system 530 3.6. NEAT Flow Termination 532 This set of primitives and events are related to gracefully or 533 forcefully closing a NEAT Flow, or being informed about this 534 happening. 536 P: CLOSE( ) 538 The CLOSE primitive terminates a NEAT Flow after satisfying all the 539 requirements that were specified regarding the delivery of data that 540 the application has already given to NEAT. If the peer still has data 541 to send, it cannot then be received after this call. Data buffered 542 by the NEAT System that has not yet been given to the network layer 543 will be discarded. 545 E: on_close 547 The on_close event informs the application that a NEAT Flow was 548 successfully closed. This can be received at any time for an active 549 NEAT Flow. 551 P: ABORT( ) 553 The ABORT primitive terminates a connection without delivering 554 remaining data. 556 E: on_aborted 558 The on_aborted event informs the application that the other side has 559 aborted the NEAT Flow. The event can be received at any time for an 560 active NEAT Flow. 562 E: on_timeout 564 The on_timeout event informs the application that the NEAT Flow is 565 aborted because the default timeout has been reached before data 566 could be delivered. This timeout adjusted by the P: CHANGE_TIMEOUT 567 NEAT Flow maintenance primitive. The event can be received at any 568 time for an active NEAT Flow. 570 3.7. NEAT Error Events 572 Errors that occur within the NEAT System or that are notified by the 573 network result in an on_error event: 575 E: on_error 577 This event notifies a hard or soft error to the upper layer using the 578 NEAT System. 580 4. Security Considerations 582 This document is about the design and usage of a transport API. The 583 transport protocols accessed via this API each have security 584 considerations. 586 The API may be used to request the use of security protocols accessed 587 via the transport API. 589 5. IANA Considerations 591 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 593 This memo includes no request to IANA. 595 6. References 597 [D1.1] Fairhurst, G., Jones, T., Damjanovic, D., Eckert, K., 598 Grinnemo, K., Hansen, A., Mangiante, S., McManus, P., 599 Papastergiou, G., Ros, D., Vyncke, E., Welzl, M. and M. 600 Tuexen, "The NEAT Architecture (D1.1)", 2015, . 603 [D2.3] Khademi, N., Bozakov, Z., Brunstroem, A., Dale, O., 604 Damjanovic, D., Evensen, KR., Fairhurst, G., Fischer, A., 605 Grinnemo, K., Jones, T., Mangiante, S., Petlund, A., Ros, 606 D., Ruengeler, I., Stenberg, D., Tuexen, M., Weinrank, F. 607 and M. Welzl, "The Final Version of Core Transport System 608 (D2.3)", 2017, . 611 [I-D.grinnemo-taps-he] 612 Grinnemo, K., Brunstrom, A., Hurtig, P., Khademi, N. and 613 Z. Bozakov, "Happy Eyeballs for Transport Selection", 614 Internet-Draft draft-grinnemo-taps-he-03, July 2017. 616 [I-D.ietf-tls-tls13] 617 Rescorla, E., "The Transport Layer Security (TLS) Protocol 618 Version 1.3", Internet-Draft draft-ietf-tls-tls13-21, July 619 2017. 621 [NEAT-DOC] 622 Stenberg, D., Weinrank, F., Khademi, N., Dreibholz, T., 623 Jones, T., Bozakov, Z. and O. Dale, "NEAT Programming API 624 Documentation", , . 626 [NEAT-GIT] 627 "NEAT Source Code Repository", , . 630 [NEAT] "The EU New, Evolutive API and Transport-Layer 631 Architecture for the Internet (NEAT) Project", 2017, 632 . 634 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S. and A. Jain, "TCP 635 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 636 . 638 [RFC8095] Fairhurst, G., Ed., Trammell, B.Ed., and M. Kuehlewind, 639 Ed., "Services Provided by IETF Transport Protocols and 640 Congestion Control Mechanisms", RFC 8095, DOI 10.17487/ 641 RFC8095, March 2017, . 644 Appendix A. Revision Information 646 -00 This is an individual draft for the IETF community, for 647 consideration by the IETF TAPS WG. 649 Authors' Addresses 650 Godred Fairhurst 651 University of Aberdeen 652 Department of Engineering 653 Fraser Noble Building 654 Aberdeen, AB24 3UE 655 Scotland 657 Email: gorry@erg.abdn.ac.uk 658 URI: http://www.erg.abdn.ac.uk/ 660 Tom Jones 661 University of Aberdeen 662 Department of Engineering 663 Fraser Noble Building 664 Aberdeen, AB24 3UE 665 Scotland 667 Email: tom@erg.abdn.ac.uk 668 URI: http://www.erg.abdn.ac.uk/ 670 Anna Brunstrom 671 Karlstad University 672 Universitetsgatan 2 673 Karlstad, 651 88 674 Sweden 676 Email: anna.brunstrom@kau.se 678 David Ros 679 Simula Research Laboratory 680 Martin Linges vei 25 681 1364 Fornebu 682 Oslo, 683 Norway 685 Email: dros@simula.no