idnits 2.17.1 draft-gjessing-taps-minset-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 7, 2016) is 2849 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SUBCATEGORY' is mentioned on line 156, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-taps-transports-11 == Outdated reference: A later version (-09) exists of draft-ietf-taps-transports-usage-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TAPS S. Gjessing 3 Internet-Draft M. Welzl 4 Intended status: Informational University of Oslo 5 Expires: January 8, 2017 July 7, 2016 7 A Minimal Set of Transport Services for TAPS Systems 8 draft-gjessing-taps-minset-02 10 Abstract 12 This draft recommends a minimal set of IETF Transport Services 13 offered by end systems supporting TAPS, and gives guidance on 14 choosing among the available mechanisms and protocols. It is based 15 on the set of transport services given in the TAPS document 16 draft-ietf-taps-transports-usage-00. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 8, 2017. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. The Superset of Transport Service Features . . . . . . . . . . 5 55 3.1. CONNECTION Related Transport Service Features . . . . . . 5 56 3.2. DATA Transfer Related Transport Service Features . . . . . 9 57 3.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . . 9 58 3.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . . 10 59 3.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . 11 60 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 61 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 65 9. Informative References . . . . . . . . . . . . . . . . . . . . 14 66 Appendix A. Revision information . . . . . . . . . . . . . . . . 14 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 69 1. Introduction 71 An application has an intended usage and demands for transport 72 services, and the task of any system that implements TAPS is to offer 73 these services to its applications, i.e. the applications running on 74 top of TAPS, without binding an application to a particular transport 75 protocol. 77 The present draft is based on [TAPS1] and [TAPS2] and follows the 78 same terminology (also listed below). The purpose of these two 79 drafts is, according to the TAPS charter, to "Define a set of 80 Transport Services, identifying the services provided by existing 81 IETF protocols and congestion control mechanisms." This is item 1 in 82 the list of working group tasks. Also according to the TAPS charter, 83 the working group will then "Specify the subset of those Transport 84 Services, as identified in item 1, that end systems supporting TAPS 85 will provide, and give guidance on choosing among available 86 mechanisms and protocols. Note that not all the capabilities of IETF 87 Transport protocols need to be exposed as Transport Services." Hence 88 it is necessary to minimize the number of services that are offered. 89 We begin this by grouping the transport service features. 91 Following [TAPS2], we divide the transport service features into two 92 main groups as follows: 93 1. CONNECTION related transport service features 94 - ESTABLISHMENT 95 - AVAILABILITY 96 - MAINTENANCE 97 - TERMINATION 98 2. DATA Transfer Related transport service features 99 - Sending Data 100 - Receiving Data 101 - Errors 103 Because QoS is out of scope of TAPS, this document assumes a "best 104 effort" service model [RFC5290], [RFC7305]. Applications using a 105 TAPS system can therefore not make any assumptions about e.g. the 106 time it will take to send a message. There are however certain 107 requirements that are strictly kept by transport protocols today, and 108 these must also be kept by a TAPS system. Some of these requirements 109 relate to transport service features that we call "Functional". 111 Functional transport service features provide functionality that 112 cannot be used without the application knowing about them, or else 113 they violate assumptions that might cause the application to fail. 114 For example, unordered message delivery is a functional transport 115 service feature: it cannot be used without the application knowing 116 about it because the application's assumption could be that messages 117 arrive in order. 119 "Change DSCP" and "Disable Nagle algorithm" are what we call 120 "Optimizing" transport service features: if a TAPS system 121 autonomously decides to enable or disable them, an application will 122 not fail, but a TAPS system may be able to communicate more 123 efficiently if the application is in control of this optimizing 124 transport service feature. "Change DSCP" and "Disable Nagle 125 algorithm" are examples of transport service features that require 126 application-specific knowledge (about delay/bandwidth requirements 127 and the length of future data blocks that are to be transmitted, 128 respectively). 130 To summarize, transport service features that this memo recommends to 131 offer to applications are divided into two groups as follows: 132 o Functional 133 This transport service feature has to be specified by the 134 application, since if not, it cannot be used or the application 135 logic may break. 136 o Optimizing 137 This transport service feature may be specified by the 138 application, and when specified can optimize the performance of 139 the application. 141 The transport service features of IETF transport protocols that are 142 not exposed to the TAPS user because they include functionality that 143 could be transparently utilized by a TAPS system are called 144 "Automatable". 146 Finally, some transport service features are aggregated or slightly 147 changed in the TAPS API. These transport service features are marked 148 as "ADDED". The corresponding transport service feature(s) is/are 149 automatable, and they are listed immediately below the "ADDED" 150 transport service feature. 152 This document also sketches how some of the TAPS transport services 153 can be implemented. Wherever it is not obvious how to implement a 154 service via TCP or UDP [**UDP: NOT YET**], a brief discussion is 155 included. IETF transport services are presented following the 156 nomenclature "CATEGORY.[SUBCATEGORY].SERVICENAME.PROTOCOL". 158 2. Terminology 160 The following terms are used throughout this document, and in 161 subsequent documents produced by TAPS that describe the composition 162 and decomposition of transport services. 164 Transport Service Feature: a specific end-to-end feature that the 165 transport layer provides to an application. Examples include 166 confidentiality, reliable delivery, ordered delivery, message- 167 versus-stream orientation, etc. 168 Transport Service: a set of Transport Features, without an 169 association to any given framing protocol, which provides a 170 complete service to an application. 171 Transport Protocol: an implementation that provides one or more 172 different transport services using a specific framing and header 173 format on the wire. 174 Transport Service Instance: an arrangement of transport protocols 175 with a selected set of features and configuration parameters that 176 implements a single transport service, e.g., a protocol stack (RTP 177 over UDP). 178 Application: an entity that uses the transport layer for end-to-end 179 delivery data across the network (this may also be an upper layer 180 protocol or tunnel encapsulation). 181 Application-specific knowledge: knowledge that only applications 182 have. 183 Endpoint: an entity that communicates with one or more other 184 endpoints using a transport protocol. 185 Connection: shared state of two or more endpoints that persists 186 across messages that are transmitted between these endpoints. 187 Socket: the combination of a destination IP address and a 188 destination port number. 190 3. The Superset of Transport Service Features 192 This section is based on the classification of the transport service 193 features in pass 3 of [TAPS2]. For every transport service feature, 194 a brief explanation of the classification is provided. Some more 195 general decisions affect multiple transport service features (e.g. 196 the decision that multi-streaming is automatable); the rationale for 197 such decisions is provided in Section 4. 199 3.1. CONNECTION Related Transport Service Features 201 ESTABLISHMENT: 202 o Connect 203 Protocols: TCP, SCTP 204 Functional because the notion of a connection is often reflected 205 in applications as an expectation to be able to communicate after 206 a "Connect" succeeded, with a communication sequence relating to 207 this transport service feature that is defined by the application 208 protocol. 209 Implementation: via CONNECT.TCP or CONNECT.SCTP. 211 o Specify IP Options 212 Protocols: TCP 213 Automatable because IP Options relate to knowledge about the 214 network, not the application. 216 o Request multiple streams 217 Protocols: SCTP 218 Automatable because using multi-streaming does not require 219 application-specific knowledge. 220 Implementation: see Section 4. 222 o Obtain multiple sockets 223 Protocols: SCTP 224 Automatable because the usage of multiple paths to communicate to 225 the same end host relates to knowledge about the network, not the 226 application. 227 Implementation: see Section 4. 229 AVAILABILITY: 230 o Listen 231 Protocols: All 232 Functional because the notion of accepting connection requests is 233 often reflected in applications as an expectation to be able to 234 communicate after a "Listen" succeeded, with a communication 235 sequence relating to this transport service feature that is 236 defined by the application protocol. 237 ADDED. This differs from the 3 automatable transport service 238 features below in that it leaves the choice of interfaces for 239 listening open. 240 Implementation: by listening on all interfaces via LISTEN.TCP (not 241 providing a local IP address) or LISTEN.SCTP (providing SCTP port 242 number / address pairs for all local IP addresses). 244 o Listen, 1 specified local interface 245 Protocols: TCP, SCTP 246 Automatable because decisions about local interfaces relate to 247 knowledge about the network and the Operating System, not the 248 application. 249 o Listen, N specified local interfaces 250 Protocols: SCTP 251 Automatable because decisions about local interfaces relate to 252 knowledge about the network and the Operating System, not the 253 application. 254 o Listen, all local interfaces 255 Protocols: TCP, SCTP 256 Automatable because decisions about local interfaces relate to 257 knowledge about the network and the Operating System, not the 258 application. 259 o Obtain requested number of streams 260 Protocols: SCTP 261 Automatable because using multi-streaming does not require 262 application-specific knowledge. 263 Implementation: see Section 4. 265 MAINTENANCE: 266 o Change timeout for aborting connection (using retransmit limit or 267 time value) 268 Protocols: TCP, SCTP 269 Functional because this is closely related to potentially assumed 270 reliable data delivery. 271 Implementation: via CHANGE-TIMEOUT.TCP or CHANGE-TIMEOUT.SCTP. 273 o Control advertising timeout for aborting connection to remote 274 endpoint 275 Protocols: TCP 276 Functional because this is closely related to potentially assumed 277 reliable data delivery. 278 Implementation: via CHANGE-TIMEOUT.TCP. 280 o Disable Nagle algorithm 281 Protocols: TCP, SCTP 282 Optimizing because this decision depends on knowledge about the 283 size of future data blocks and the delay between them. 284 Implementation: via DISABLE-NAGLE.TCP and [**Not yet included in 285 [TAPS2] FOR SCTP**]. 287 o Request an immediate heartbeat, returning success/failure 288 Protocols: SCTP 289 Automatable because this informs about network-specific knowledge. 291 o Set protocol parameters 292 Protocols: SCTP 293 SCTP parameters: RTO.Initial; RTO.Min; RTO.Max; Max.Burst; 294 RTO.Alpha; RTO.Beta; Valid.Cookie.Life; Association.Max.Retrans; 295 Path.Max.Retrans; Max.Init.Retransmits; HB.interval; HB.Max.Burst 296 Automatable because these parameters relate to knowledge about the 297 network, not the application. 299 o Notification of Excessive Retransmissions (early warning below 300 abortion threshold) 301 Protocols: TCP 302 Optimizing because it is an early warning to the application, 303 informing it of an impending functional event. 304 Implementation: via ERROR.TCP. 306 o Notification of ICMP error message arrival 307 Protocols: TCP 308 Optimizing because these messages can inform about success or 309 failure of functional transport service features (e.g., host 310 unreachable relates to "Connect") 311 Implementation: via ERROR.TCP. 313 o Status (query or notification) 314 Protocols: SCTP 315 SCTP parameters: association connection state; socket list; socket 316 reachability states; current receiver window size; current 317 congestion window sizes; number of unacknowledged DATA chunks; 318 number of DATA chunks pending receipt; primary path; most recent 319 SRTT on primary path; RTO on primary path; SRTT and RTO on other 320 destination addresses; socket becoming active / inactive 321 Automatable because these parameters relate to knowledge about the 322 network, not the application. 324 o Set primary path 325 Protocols: SCTP 326 Automatable because it requires using multiple sockets, but 327 obtaining multiple sockets in the CONNECTION.ESTABLISHMENT 328 category is automatable. 329 Implementation: see Section 4. 331 o Change DSCP 332 Protocols: TCP 333 Optimizing because choosing a suitable DSCP value requires 334 application-specific knowledge. 335 Implementation: via CHANGE-DSCP.TCP and [**Not yet included in 336 [TAPS2] FOR SCTP**] 338 TERMINATION: 339 o Close after reliably delivering all remaining data, causing an 340 event informing the application on the other side 341 Protocols: TCP, SCTP 342 Functional because the notion of a connection is often reflected 343 in applications as an expectation to have all outstanding data 344 delivered and no longer be able to communicate after a "Close" 345 succeeded, with a communication sequence relating to this 346 transport service feature that is defined by the application 347 protocol. 348 Implementation: via CLOSE.TCP and CLOSE.SCTP. 350 o Abort without delivering remaining data, causing an event 351 informing the application on the other side 352 Protocols: TCP, SCTP 353 Functional because the notion of a connection is often reflected 354 in applications as an expectation to potentially not have all 355 outstanding data delivered and no longer be able to communicate 356 after an "Abort" succeeded, with a communication sequence relating 357 to this transport service feature that is defined by the 358 application protocol. 359 Implementation: via ABORT.TCP and ABORT.SCTP. 361 o Timeout event when data could not be delivered for too long 362 Protocols: TCP, SCTP 363 Functional because this notifies that potentially assumed reliable 364 data delivery is no longer provided. Implementation: via 365 TIMEOUT.TCP and TIMEOUT.SCTP. 367 3.2. DATA Transfer Related Transport Service Features 369 3.2.1. Sending Data 371 o Reliably transfer data 372 Protocols: TCP, SCTP 373 Functional because this is closely tied to properties of the data 374 that an application sends or expects to receive. 375 Implementation: via SEND.TCP and SEND.SCTP. 377 o Message identification 378 Protocols: SCTP 379 Functional because this is closely tied to properties of the data 380 that an application sends or expects to receive. 381 Implementation: via SEND.SCTP. 382 Fall-back to TCP: By using SEND.TCP and providing a means to let 383 the application query whether messages can be identified or not. 385 o Choice of stream 386 Protocols: SCTP 387 Automatable because it requires using multiple streams, but 388 requesting multiple streams in the CONNECTION.ESTABLISHMENT 389 category is automatable. Implementation: see Section 4. 391 o Choice of path (destination address) 392 Protocols: SCTP 393 Automatable because it requires using multiple sockets, but 394 obtaining multiple sockets in the CONNECTION.ESTABLISHMENT 395 category is automatable. Implementation: see Section 4. 397 o Message lifetime 398 Protocols: SCTP 399 Optimizing because only applications know about the time 400 criticality of their communication. 401 Implementation: via SEND.SCTP. 402 Fall-back to TCP: By using SEND.TCP and ignoring the lifetime 403 request: based on the assumption of the best-effort service model, 404 unnecessarily delivering data does not violate application 405 expectations. Moreover, it is not possible to associate the 406 requested lifetime to a "message" in TCP anyway. 408 o Choice between unordered (potentially faster) or ordered delivery 409 of messages 410 Protocols: SCTP 411 Functional because this is closely tied to properties of the data 412 that an application sends or expects to receive. 413 Implementation: via SEND.SCTP. 414 Fall-back to TCP: By using SEND.TCP and always sending data 415 ordered: based on the assumption of the best-effort service model, 416 ordered delivery may just be slower and does not violate 417 application expectations. Moreover, it is not possible to 418 associate the requested delivery order to a "message" in TCP 419 anyway. 421 o Request not to bundle messages 422 Protocols: SCTP 423 Optimizing because this decision depends on knowledge about the 424 size of future data blocks and the delay between them. 425 Implementation: via SEND.SCTP. 426 Fall-back to TCP: By using SEND.TCP and DISABLE-NAGLE.TCP to 427 disable the Nagle algorithm when the request is made and enable it 428 again when the request is no longer made. 430 o Specifying a "payload protocol-id" (handed over as such by the 431 receiver) 432 Protocols: SCTP 433 Functional because it allows to send extra application data with 434 every message, for the sake of identification of data, which by 435 itself is application-specific. 436 Implementation: SEND.SCTP. 437 Fall-back to TCP: Not possible. 439 3.2.2. Receiving Data 441 o Receive data 442 Protocols: TCP, SCTP 443 Functional because a TAPS system must be able to send and receive 444 data. 445 Implementation: via RECEIVE.SCTP and RECEIVE.TCP 447 o Choice of stream to receive from 448 Protocols: SCTP 449 Automatable because it requires using multiple streams, but 450 requesting multiple streams in the CONNECTION.ESTABLISHMENT 451 category is automatable. 452 Implementation: see Section 4. 454 o Message identification 455 Protocols: SCTP 456 Functional because this is closely tied to properties of the data 457 that an application sends or expects to receive. 458 Implementation: via RECEIVE.SCTP. 459 Fall-back to TCP: By using RECEIVE.TCP and providing a means to 460 let the application query whether messages can be identified or 461 not. 463 o Information about partial message arrival 464 Protocols: SCTP 465 Functional because this is closely tied to properties of the data 466 that an application sends or expects to receive. 467 Implementation: via RECEIVE.SCTP. 468 Fall-back to TCP: Not possible (do not provide this event). 470 3.2.3. Errors 472 o Notification of send failures 473 Protocols: TCP, SCTP 474 Functional because this notifies that potentially assumed reliable 475 data delivery is no longer provided. 476 ADDED. This differs from the 2 automatable transport service 477 features below in that it does not distinugish between unsent and 478 unacknowledged messages. 479 Implementation: via SENDFAILURE-EVENT.SCTP. 480 Fall-back to TCP: Not possible (do not provide this event). 482 o Notification of unsent messages 483 Protocols: SCTP 484 Automatable because the distinction between unsent and 485 unacknowledged is network-specific. 486 o Notification of unacknowledged messages 487 Protocols: SCTP 488 Automatable because the distinction between unsent and 489 unacknowledged is network-specific. 491 4. Discussion 493 Some of transport service features in Section 3 were designated as 494 "automatable" on the basis of a broader decision that affects 495 multiple transport service features. These decisions are explained 496 here: 497 o All transport service features that are related to multi-streaming 498 were removed. The decision on whether to use multi-streaming or 499 not does not depend on application-specific knowledge. This means 500 that a connection that is exhibited to an application could be 501 implemented by using a single stream of an SCTP association 502 instead of mapping it to a complete SCTP association. This could 503 be achieved by using more than one stream when an SCTP association 504 is first established (CONNECT.SCTP parameter "outbound stream 505 count"), an internal stream number could be maintained by the TAPS 506 system, and this stream number would then be used when sending 507 data (SEND.SCTP parameter "stream number"). Closing or aborting a 508 connection could then simply free the stream number for future 509 use. 510 o All transport service features that are related to usage of 511 multiple paths or the choice of the network interface were 512 removed. Choosing a path or an interface does not depend on 513 application-specific knowledge. For example, "Listen" could 514 always listen on all available interfaces and "Connect" could use 515 the default interface for the destination IP address. 517 5. Conclusion 519 By decoupling applications from transport protocols, a TAPS system 520 provides a different abstraction level than the Berkeley sockets 521 interface. As with high- vs. low-level programming languages, a 522 higher abstraction level allows more freedom for automatization below 523 the interface, yet it takes some control away from the application 524 programmer. This is the design trade-off that a TAPS system 525 developer is facing, and this document provides guidance on the 526 design of this abstraction level. Some transport service features 527 are currently rarely offered by APIs, yet they must be offered or 528 they can never be used ("functional" transport service features). 529 Other transport service features are offered by the APIs of the 530 protocols covered here, but not exposing them in a TAPS API would 531 allow for more freedom to automate protocol usage in a TAPS system. 533 The eventual recommendations are: 534 o A TAPS system should expose all functional transport service 535 features that are offered by the transport protocols that it uses 536 because these transport service features could otherwise not be 537 utilized by the TAPS system. It can still be possible to 538 implement a TAPS system that does not offer all functional 539 transport service features, e.g. for the sake of uniform 540 application operation across a broader set of protocols, but then 541 the corresponding functionality of transport protocols is not 542 exploited. If a protocol that provides a functional transport 543 service feature is not available, a TAPS system should 544 automatically fall back to a different protocol (e.g. TCP or UDP) 545 whenever possible to reduce the potential for protocol dependence 546 in applications. 547 o A TAPS system should exhibit all application-specific optimizing 548 transport service features. If an application-specific optimizing 549 transport service feature is only available in a subset of the 550 transport protocols used by the TAPS system, it should be 551 acceptable for the TAPS system to ignore its usage when the 552 transport protocol that is currently used does not provide it 553 because of the performance-optimizing nature of the transport 554 service feature and the initially mentioned assumption of "best 555 effort" operation. 556 o By hiding automatable transport service features from the 557 application, a TAPS system can gain opportunities to automatize 558 network-related functionality. This can facilitate using the TAPS 559 system for the application programmer and it allows for 560 optimizations that may not be possible for an application. For 561 instance, a kernel-level TAPS system that hides SCTP multi- 562 streaming from applications could theoretically map application- 563 level connections from multiple applications onto the same SCTP 564 association. Similarly, system-wide configurations regarding the 565 usage of multiple interfaces could be exploited if the choice of 566 the interface is not given to the application. However, if an 567 application wants to directly expose such choices to its user, not 568 offering this functionality can become a disadvantage of a TAPS 569 system. This is a trade-off that must be considered in TAPS 570 system design. 572 6. Acknowledgements 574 This work has received funding from the European Union's Horizon 2020 575 research and innovation programme under grant agreement No. 644334 576 (NEAT). The views expressed are solely those of the author(s). 578 7. IANA Considerations 580 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 582 This memo includes no request to IANA. 584 8. Security Considerations 586 Security will be considered in future versions of this document. 588 9. Informative References 590 [RFC5290] Floyd, S. and M. Allman, "Comments on the Usefulness of 591 Simple Best-Effort Traffic", RFC 5290, DOI 10.17487/ 592 RFC5290, July 2008, 593 . 595 [RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet 596 Technology Adoption and Transition (ITAT)", RFC 7305, 597 DOI 10.17487/RFC7305, July 2014, 598 . 600 [TAPS1] Fairhurst, G., Trammell, B., and M. Kuehlewind, "Services 601 provided by IETF transport protocols and congestion 602 control mechanisms", draft-ietf-taps-transports-11 (work 603 in progress), July 2016. 605 [TAPS2] Welzl, M., Tuexen, M., and N. Khademi, "An Approach to 606 Identify Services Provided by IETF Transport Protocols and 607 Congestion Control Mechanisms", 608 draft-ietf-taps-transports-usage-00 (work in progress), 609 June 2015. 611 Appendix A. Revision information 613 XXX RFC-Ed please remove this section prior to publication. 615 -02: implementation suggestions added, discussion section added, 616 terminology extended, DELETED category removed, various other fixes; 617 list of Transport Service Features adjusted to -01 version of [TAPS2] 618 except that MPTCP is not included. 620 Authors' Addresses 622 Stein Gjessing 623 University of Oslo 624 PO Box 1080 Blindern 625 Oslo, N-0316 626 Norway 628 Phone: +47 22 85 24 44 629 Email: steing@ifi.uio.no 631 Michael Welzl 632 University of Oslo 633 PO Box 1080 Blindern 634 Oslo, N-0316 635 Norway 637 Phone: +47 22 85 24 20 638 Email: michawe@ifi.uio.no