idnits 2.17.1 draft-ietf-taps-transports-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 : ---------------------------------------------------------------------------- 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 (December 15, 2014) is 3413 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0791' is defined on line 234, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 237, but no explicit reference was found in the text == Unused Reference: 'RFC0896' is defined on line 248, but no explicit reference was found in the text == Unused Reference: 'RFC1122' is defined on line 251, but no explicit reference was found in the text == Unused Reference: 'RFC2018' is defined on line 254, but no explicit reference was found in the text == Unused Reference: 'RFC3168' is defined on line 257, but no explicit reference was found in the text == Unused Reference: 'RFC3390' is defined on line 264, but no explicit reference was found in the text == Unused Reference: 'RFC5348' is defined on line 281, but no explicit reference was found in the text == Unused Reference: 'RFC5405' is defined on line 285, but no explicit reference was found in the text == Unused Reference: 'RFC5925' is defined on line 289, but no explicit reference was found in the text == Unused Reference: 'RFC5681' is defined on line 292, but no explicit reference was found in the text == Unused Reference: 'RFC6093' is defined on line 295, but no explicit reference was found in the text == Unused Reference: 'RFC6298' is defined on line 298, but no explicit reference was found in the text == Unused Reference: 'RFC6691' is defined on line 305, but no explicit reference was found in the text == Unused Reference: 'RFC7323' is defined on line 308, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 896 (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 3205 (Obsoleted by RFC 9205) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) -- Obsolete informational reference (is this intentional?): RFC 6093 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 6691 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 16 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Fairhurst, Ed. 3 Internet-Draft University of Aberdeen 4 Intended status: Informational B. Trammell, Ed. 5 Expires: June 18, 2015 ETH Zurich 6 December 15, 2014 8 Services provided by IETF transport protocols and congestion control 9 mechanisms 10 draft-ietf-taps-transports-00 12 Abstract 14 This document describes services provided by existing IETF protocols 15 and congestion control mechanisms. It is designed to help 16 application and network stack programmers and to inform the work of 17 the IETF TAPS Working Group. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on June 18, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 1. Introduction 53 Most Internet applications make use of the Transport Services 54 provided by TCP (a reliable, in-order stream protocol) or UDP (an 55 unreliable datagram protocol). We use the term "Transport Service" 56 to mean an end-to-end facility provided by the transport layer. That 57 service can only be provided correctly if information is supplied 58 from the application. The application may determine the information 59 to be supplied at design time, compile time, or run time and may 60 include guidance on whether an aspect of the service is required, a 61 preference by the application, or something in between. Examples of 62 Transport service facilities are reliable delivery, ordered delivery, 63 content privacy to in-path devices, integrity protection, and minimal 64 latency. 66 Transport protocols such as SCTP, DCCP, MPTCP, UDP and UDP-Lite have 67 been defined at the transport layer. 69 In addition, a transport service may be built on top of these 70 transport protocols, using a fraemwork such as WebSockets, or RTP. 71 Service built on top of UDP or UDP-Lite typically also need to 72 specify a congestion control mechanism, such as TFRC or the LEDBAT 73 congestion control mechanism. This extends the set of available 74 Transport Services beyond those provided to applications by TCP and 75 UDP. 77 Transport services can aslo be differentiated by the services they 78 provide: for instance, SCTP offers a message-based service that does 79 not suffer head-of-line blocking when used with multiple stream, 80 because it can accept blocks of data out of order, UDP-Lite provides 81 partial integrity protection when used over link-layer services that 82 can support this, and LEDBAT can provide low-priority "scavenger" 83 communication. 85 2. Terminology 87 The following terms are defined throughout this document, and in 88 subsequent documents produced by TAPS describing the composition and 89 decomposition of transport services. 91 The terminology below is that as was presented at the TAPS WG meeting 92 in Honolulu. While the factoring of the terminology seems 93 uncontroversial, thre may be some entities which still require names 94 (e.g. information about the interface between the transport and lower 95 layers which could lead to the availablity or unavailibility of 96 certain transport protocol features) 98 Transport Service Feature: a specific feature a transport service 99 provides to its clients end-to-end. Examples include 100 confidentiality, reliable delivery, ordered delivery, message- 101 versus-stream orientation, etc. 103 Transport Service: a set of transport service features, without an 104 association to any given framing protocol, which provides a 105 complete service to an application. 107 Transport Protocol: an implementation that provides one or more 108 different transport services using a specific framing and header 109 format on the wire. 111 Transport Protocol Component: an implementation of a transport 112 service feature within a protocol 114 Transport Service Instance: an arrangement of transport protocols 115 with a selected set of features and configuration parameters that 116 implements a single transport service, e.g. a protocol stack (RTP 117 over UDP) 119 Application: an entity that uses the transport layer for end-to-end 120 delivery data across the network. 122 3. Transport Protocols 124 This section provides a list of known IETF transport protocol and 125 transport protocol frameworks. 127 3.1. Transport Control Protocol (TCP) 129 TCP [RFC0793] provides a bidirectional byte-oriented stream over a 130 connection- oriented protocol. The protocol and API use the byte- 131 stream model. 133 [EDITOR'S NOTE: Mirja Kuehlewind signed up as contributor for this 134 section.] 136 3.1.1. Multipath TCP (MPTCP) 138 3.2. Stream Control Transmission Protocol (SCTP) 140 SCTP [RFC4960] provides a bidirectional set of logical unicast 141 streams over one a connection-oriented protocol. The protocol and 142 API use messages, rather than a byte-stream. Each stream of messages 143 is independently managed, therefore retransmission does not hold back 144 data sent using other logical streams. 146 [EDITOR'S NOTE: Michael Tuexen and Karen Nielsen signed up as 147 contributors for these sections.] 149 3.2.1. Partial Reliability for SCTP (PR-SCTP) 151 PR-SCTP [RFC3758] is a variant of SCTP that provides partial 152 reliability. 154 3.3. User Datagram Protocol (UDP) 156 The User Datagram Protocol (UDP) [RFC0768] provides a unidirectional 157 minimal message-passing transport that has no inherent congestion 158 control mechanisms. The service may be multicast and/or unicast. 160 [EDITOR'S NOTE: Kevin Fall signed up as contributor for this 161 section.] 163 3.3.1. UDP-Lite 165 A special class of applications can derive benefit from having 166 partially-damaged payloads delivered, rather than discarded, when 167 using paths that include error-prone links. Such applications can 168 tolerate payload corruption and may choose to use the Lightweight 169 User Datagram Protocol [RFC3828]. The service may be multicast and/ 170 or unicast. 172 3.4. Datagram Congestion Control Protocol (DCCP) 174 The Datagram Congestion Control Protocol (DCCP) [RFC4340] is a 175 bidirectional transport protocol that provides unicast connections of 176 congestion-controlled unreliable messages. DCCP is suitable for 177 applications that transfer fairly large amounts of data and that can 178 benefit from control over the tradeoff between timeliness and 179 reliability. 181 3.5. Realtime Transport Protocol (RTP) 183 RTP provides an end-to-end network transport service, suitable for 184 applications transmitting real-time data, such as audio, video or 185 data, over multicast or unicast network services, including TCP, UDP, 186 UDP-Lite, DCCP. 188 [EDITOR'S NOTE: Varun Singh signed up as contributor for this 189 section.] 191 3.6. Hypertext Transport Protocol (HTTP) as a pseudotransport 193 [RFC3205] 195 3.6.1. WebSockets 197 [RFC6455] 199 4. Transport Service Features 201 Features as derived from the subsections above. 203 This section is blank for now. 205 5. IANA Considerations 207 This document has no considerations for IANA. 209 6. Security Considerations 211 This document surveys existing transport protocols and protocols 212 providing transport-like services. Confidentiality, integrity, and 213 authenticity are among the features provided by those services. This 214 document does not specify any new components or mechanisms for 215 providing these features. Each RFC listed in this document discusses 216 the security considerations of the specification it contains. 218 7. Contributors 220 Non-editor contributors of text will be listed here, as in the 221 authors section. 223 8. Acknowledgments 225 This work is partially supported by the European Commission under 226 grant agreement FP7-ICT-318627 mPlane; support does not imply 227 endorsement. Special thanks to Mirja Kuehlewind for the terminology 228 section and for leading the terminology discussion in Honolulu. 230 9. References 232 9.1. Normative References 234 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 235 1981. 237 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 238 (IPv6) Specification", RFC 2460, December 1998. 240 9.2. Informative References 242 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 243 August 1980. 245 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 246 793, September 1981. 248 [RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks", 249 RFC 896, January 1984. 251 [RFC1122] Braden, R., "Requirements for Internet Hosts - 252 Communication Layers", STD 3, RFC 1122, October 1989. 254 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 255 Selective Acknowledgment Options", RFC 2018, October 1996. 257 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 258 of Explicit Congestion Notification (ECN) to IP", RFC 259 3168, September 2001. 261 [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, 262 RFC 3205, February 2002. 264 [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's 265 Initial Window", RFC 3390, October 2002. 267 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 268 Conrad, "Stream Control Transmission Protocol (SCTP) 269 Partial Reliability Extension", RFC 3758, May 2004. 271 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 272 G. Fairhurst, "The Lightweight User Datagram Protocol 273 (UDP-Lite)", RFC 3828, July 2004. 275 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 276 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 278 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 279 4960, September 2007. 281 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 282 Friendly Rate Control (TFRC): Protocol Specification", RFC 283 5348, September 2008. 285 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 286 for Application Designers", BCP 145, RFC 5405, November 287 2008. 289 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 290 Authentication Option", RFC 5925, June 2010. 292 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 293 Control", RFC 5681, September 2009. 295 [RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the 296 TCP Urgent Mechanism", RFC 6093, January 2011. 298 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 299 "Computing TCP's Retransmission Timer", RFC 6298, June 300 2011. 302 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 303 6455, December 2011. 305 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 306 RFC 6691, July 2012. 308 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 309 Scheffenegger, "TCP Extensions for High Performance", RFC 310 7323, September 2014. 312 Authors' Addresses 314 Godred Fairhurst (editor) 315 University of Aberdeen 316 School of Engineering, Fraser Noble Building 317 Aberdeen AB24 3UE 319 Email: gorry@erg.abdn.ac.uk 321 Brian Trammell (editor) 322 ETH Zurich 323 Gloriastrasse 35 324 8092 Zurich 325 Switzerland 327 Email: ietf@trammell.ch