idnits 2.17.1 draft-fairhurst-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 : ---------------------------------------------------------------------------- ** There are 36 instances of too long lines in the document, the longest one being 6 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 (October 27, 2014) is 3468 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3758' is mentioned on line 194, but not defined == Missing Reference: 'RFC3828' is mentioned on line 224, but not defined == Unused Reference: 'RFC0791' is defined on line 290, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 293, but no explicit reference was found in the text == Unused Reference: 'RFC0768' is defined on line 298, but no explicit reference was found in the text == Unused Reference: 'RFC0793' is defined on line 301, but no explicit reference was found in the text == Unused Reference: 'RFC0896' is defined on line 304, but no explicit reference was found in the text == Unused Reference: 'RFC4960' is defined on line 310, but no explicit reference was found in the text == Unused Reference: 'RFC5348' is defined on line 313, but no explicit reference was found in the text == Unused Reference: 'RFC5405' is defined on line 317, 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 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Fairhurst 3 Internet-Draft University of Aberdeen 4 Intended status: Informational B. Trammell 5 Expires: April 30, 2015 ETH Zurich 6 October 27, 2014 8 Services provided by IETF transport protocols and congestion control 9 mechanisms 10 draft-fairhurst-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 April 30, 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 This section presents the terminology used in this document. 89 [EDITOR'S NOTE: Terminology to be discussed in Honolulu. We need to 90 determine what a "service" as used by the IETF, as opposed to a 91 "service component", "property", an "aspect", "dimension", etc.] 93 3. Transport Protocols 95 This section provides a list of known IETF transport protocol and 96 transport protocol frameworks. 98 [EDITOR'S NOTE: combine these tables into one? Also, reorder them to 99 match ths sections below.] 101 +---------+-------------------------------------+------+---------------------+ 102 | Section | Benefit | Setup| Mode | 103 +---------+-------------------------------------+------+---------------------+ 104 | 3.1 | Transmission Control Protocol (TCP) | CO | Unicast | 105 | 3.1.1 | Multipath-TCP (MPTCP) | CO | Unicast | 106 | 3.2 | SCTP | CO | Unicast | 107 | 3.2.1 | SCTP-PR | CO | Unicast | 108 | 3.3 | User Datagram Protocol (UDP) | DG | Unicast/Multicst | 109 | 3.4 | UDP-Lite | DG | Unicast/Multicst | 110 | 3.5 | DCCP | CO | Unicast | 111 | 3.X | More as needed | | | 112 +---------+-------------------------------------+------+---------------------+ 114 Table 1: Key IETF Transport Protocol - by cmmunication mode 116 +---------+-------------------------------------+------+---------------------+ 117 | Section | Benefit | Style| Reliability | 118 +---------+-------------------------------------+------+---------------------+ 119 | 3.1 | Transmission Control Protocol (TCP) | Str | Ordered Byte Stream | 120 | 3.1.1 | Multipath-TCP (MPTCP) | Str | Ordered Byte Stream | 121 | 3.2 | SCTP | Mess | Message Streams | 122 | 3.2.1 | SCTP-PR | Mess | Partial M Streams | 123 | 3.3 | User Datagram Protocol (UDP) | Mess | Datagram Message | 124 | 3.4 | UDP-Lite | Mess | Error Tolerant DG | 125 | 3.5 | DCCP | Mess | Unrel Message Stream| 126 | 3.X | More as needed | | | 127 +---------+-------------------------------------+------+---------------------+ 129 Table 2: Key IETF Transport Protocol - by reliability 131 "Setup" defines whether the protocol performs a connection-oriented 132 protocol handshake prior o communication or is datagram based. This 133 provides reliable negotiation of options, including negotiation of a 134 suitable congestion control mechanism.This property can impact the 135 ability of the protocol to traverse firewalls. 137 +---------+-------------------------------------+----------------------------+ 138 | Section | Benefit | Congestion Control | 139 +---------+-------------------------------------+----------------------------+ 140 | 3.1 | Transmission Control Protocol (TCP) | Yes | 141 | 3.1.1 | Multipath-TCP (MPTCP) | Yes (Multipath) | 142 | 3.2 | SCTP | Yes | 143 | 3.2.1 | SCTP-PR | Yes | 144 | 3.3 | User Datagram Protocol (UDP) | At application layer | 145 | 3.4 | UDP-Lite | At application layer | 146 | 3.5 | DCCP | Yes, Various CCIDs defined | 147 | 3.X | More as needed | | 148 +---------+-------------------------------------+----------------------------+ 150 Table 3: Key IETF Transport Protocol - by congestion control 152 Some other protocol frameworks that may potentially be considered for 153 inclusion in future versions of this document. Examples are: 155 o Multicast - RMT 157 o RTP-based methods 159 o HTTP-based methods 161 o TLS 163 o DTLS 165 The following subsections describes each of these transports. 167 3.1. Transport Control Protocol (TCP) 169 TCP provides a bidirectional byte-oriented stream over a connection- 170 oriented protocol. The protocol and API use the byte-stream model. 172 [EDITOR'S NOTE: Describe the aspects(?) of TCP: reliable, connection- 173 oriented, congestion-controlled, single-stream-oriented, non- 174 boundary-preserving... Note that we want to describe the 175 characteristics of the SOCK_STREAM API as well as just the wire 176 protocol.] 178 3.1.1. Multipath TCP (MPTCP) 180 [EDITOR'S NOTE: aspects of MPTCP beyond TCP.] 182 3.2. Stream Control Transmission Protocol (SCTP) 184 This section will describe SCTP. 186 SCTP provides a bidirectional set of logical unicast streams over one 187 a connection-oriented protocol. The protocol and API use messages, 188 rather than a byte-stream. Each stream of messages is independently 189 managed, therefore retransmission does not hold back data sent using 190 other logical streams 192 3.2.1. Partial Reliability SCTP (PR-CTP) 194 SCTP-PR [RFC3758] is a variant of SCTP that provides partial 195 reliability. 197 3.3. User Datagram Protocol (UDP) 199 The User Datagram Protocol (UDP) provides a unidirectional minimal 200 message-passing transport that has no inherent congestion control 201 mechanisms. The service may be multicast and/or unicast. 203 [EDITOR'S NOTE: Describe the aspects(?) of UDP: unreliable, 204 congestion control to be applied above the transport, datagram- 205 oriented, connectionless, boundary-preserving... Note that we want to 206 describe the characteristics of the SOCK_DGRAM API as well as just 207 the wire protocol.] 209 Using UDP robustly requires each application to implement a raft of 210 functions (mostly re-inventing or adaptng mechansism already found in 211 TCP, SCTP and DCCP). [EDITOR'S NOTE: reference RFC 5405/bis ] 213 3.4. UDP-Lite 215 A special class of applications can derive benefit from having 216 partially-damaged payloads delivered, rather than discarded, when 217 using paths that include error-prone links. Such applications can 218 tolerate payload corruption and may choose to use the Lightweight 219 User Datagram Protocol (UDP-Lite) The service may be multicast and/or 220 unicast 222 [EDITOR'S NOTE: compare to UDP] 224 [RFC3828] and [RFC 5405/bis] 226 3.5. Datagram Congestion Control Protocl (DCCP) 228 The Datagram Congestion Control Protocol (DCCP) [RFC4340] is a 229 bidirectional transport protocol that provides unicast connections of 230 congestion-controlled unreliable messages. DCCP is suitable for 231 applications that transfer fairly large amounts of data and that can 232 benefit from control over the tradeoff between timeliness and 233 reliability. 235 [EDITOR'S NOTE: Describe the aspects(?) of DCCP...] 237 [FC4340 et al] 239 3.6. Realtime Transport Protocol (RTP) 241 RTP provides an end-to-end network transport service, suitable for 242 applications transmitting real-time data, such as audio, video or 243 data, over multicast or unicast network services, including TCP, UDP, 244 UDP-Lite, DCCP. 246 [EDITOR'S NOTE: Describe the aspects(?) of RTP...] 248 3.7. Hypertext Transport Protocol (HTTP) as a pseudotransport 250 HTTP provides end-to-end network unicast transport service. 252 [EDITOR'S NOTE: Reference BCP 56, note that this implies TCP but also 253 brings with it object semantics you may not want.] 255 3.7.1. WebSockets 257 [EDITOR'S NOTE: point out how websockets kind of fixes this.] 259 4. Transport service components 261 Aspects as derived from the subsections above. 263 This section is blank for now. 265 5. Acknowledgements 267 The authors were part-funded by the European Community under its 268 Seventh Framework Programme. The views expressed are solely those of 269 the authors. 271 Comments are welcome to the authors or via the IETF TAPS mailing 272 lists. 274 6. IANA Considerations 276 XXX RFC ED - PLEASE REMOVE THIS SECTION XXX 278 This memo includes no request to IANA. 280 7. Security Considerations 282 This document introduces no new security considerations. Each RFC 283 listed in this document discusses the security considerations of the 284 specification it contains. 286 8. References 288 8.1. Normative References 290 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 291 1981. 293 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 294 (IPv6) Specification", RFC 2460, December 1998. 296 8.2. Informative References 298 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 299 August 1980. 301 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 302 793, September 1981. 304 [RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks", 305 RFC 896, January 1984. 307 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 308 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 310 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 311 4960, September 2007. 313 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 314 Friendly Rate Control (TFRC): Protocol Specification", RFC 315 5348, September 2008. 317 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 318 for Application Designers", BCP 145, RFC 5405, November 319 2008. 321 Authors' Addresses 323 Godred Fairhurst 324 University of Aberdeen 325 School of Engineering, Fraser Noble Building 326 Aberdeen AB24 3UE 327 UK 329 Email: gorry@erg.abdn.ac.uk 331 Brian Trammell 332 ETH Zurich 333 Gloriastrasse 35 334 Zurich 8092 335 CH 337 Email: ietf@trammell.ch