idnits 2.17.1 draft-moncaster-tsvwg-transport-services-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 (October 18, 2013) is 3842 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3550' is defined on line 293, but no explicit reference was found in the text == Unused Reference: 'I-D.dreibholz-tsvwg-sctpsocket-multipath' is defined on line 328, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) == Outdated reference: A later version (-28) exists of draft-dreibholz-tsvwg-sctpsocket-multipath-06 == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-sctp-dtls-encaps-01 == Outdated reference: A later version (-02) exists of draft-iyengar-minion-protocol-01 == Outdated reference: A later version (-27) exists of draft-tuexen-tsvwg-sctp-multipath-07 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area T. Moncaster, Ed. 3 Internet-Draft University of Cambridge 4 Intended status: Informational M. Welzl 5 Expires: April 21, 2014 University of Oslo 6 D. Ros 7 Telecom Bretagne 8 October 18, 2013 10 Problem Statement: Why the IETF Needs Defined Transport Services 11 draft-moncaster-tsvwg-transport-services-00 13 Abstract 15 The IETF has defined a wide range of transport protocols over the 16 past three decades. However, the majority of these have failed to 17 find traction within the Internet. This has left developers with 18 little choice but to use TCP and UDP for most applications. In many 19 cases the developer isn't interested in which transport protocol they 20 should use. Rather they are interested in the set of services that 21 the protocol provides to their application. TCP provides a very rich 22 set of transport services, but offers no flexibility over which 23 services can be used. By contrast, UDP provides a minimal set of 24 services. 26 As a consequence many developers have begun to write application- 27 level transport protocols that operate on top of UDP and offer them 28 some of the flexibility they are looking for. We believe that this 29 highlights a real problem: applications would like to be able to 30 specify the services they receive from the transport protocol, but 31 currently transport protocols are not defined in this fashion. There 32 is an additional problem relating to how to ensure new protocols are 33 able to be adopted within the Internet, but that is beyond the scope 34 of this problem statement. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on April 21, 2014. 53 Copyright Notice 55 Copyright (c) 2013 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Transport Services . . . . . . . . . . . . . . . . . . . . . 3 72 2.1. Identifying Transport Services . . . . . . . . . . . . . 3 73 2.2. Exposing Transport Services . . . . . . . . . . . . . . . 4 74 3. Why Now? . . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 77 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 7. Contributors and Acknowledgements . . . . . . . . . . . . . . 6 79 8. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 6 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 82 9.2. Informative References . . . . . . . . . . . . . . . . . 7 84 1. Introduction 86 The IETF has defined a wide array of transport protocols including 87 UDP [RFC0768], TCP [RFC0793], SCTP [RFC4960], UDP-Lite [RFC3828], 88 DCCP [RFC4340] and MPTCP [RFC6824]. In most cases new protocols have 89 been defined because the IETF has established that there is a need 90 for a set of behaviours than cannot be offered by any existing 91 transport protocol. 93 However, for an application programmer, using protocols other than 94 TCP or UDP can be hard: not all protocols are available everywhere, 95 hence a fall-back solution to TCP or UDP must be implemented. Some 96 protocols provide the same services in different ways. Layering 97 decisions must be made (e.g. should a protocol be used natively or 98 over UDP?). Because of these complications, programmers often resort 99 to either using TCP (even if there is a mismatch between the services 100 provided by TCP and the services needed by the application) or 101 implementing their own customised solution over UDP, and the 102 opportunity of benefiting from other transport protocols is lost. 103 Since all these protocols were developed to provide services that 104 solve particular problems, the inability of applications to make use 105 of them is in itself a problem. 107 We believe this mismatch between the application layer and transport 108 layer can be addressed in a simple fashion. If the socket interface 109 provided a way for applications to request transport services without 110 specifying the protocol, a transport system underneath the socket API 111 could automatically try to make the best of its available resources. 112 It could use available transport protocols in a way that is most 113 beneficial for applications and without the application needing to 114 worry about problems with middlebox traversal. Adopting this 115 approach could give more freedom for diversification to designers of 116 Operating Systems. 118 2. Transport Services 120 The transport layer provides many services both to the end 121 application (e.g. multiplexing, flow control, ordering, reliability) 122 and to the network (e.g. congestion control). For the purposes of 123 this document we define Transport Services as follows: 125 o A Transport Service is any service provided by the transport layer 126 that can only be correctly implemented with information from the 127 application. 129 The key word here is "information" -- many existing transport 130 protocols function perfectly adequately because the choice of 131 protocol implicitly includes information about the desired transport 132 capabilities. For instance the choice of TCP implies a desire for 133 reliable, in-order data delivery. However we think that such 134 implicit information is not always sufficient. The rest of this 135 section explains how we propose to identify Transport Services and 136 how those services might then be exposed to the application. 138 2.1. Identifying Transport Services 139 One of the key aspects of this work is how to actually identify which 140 Transport Services should be supported. The top-down approach to 141 this would be to identify every possible service that popular 142 applications might need. The problem with this method is that every 143 potential service becomes an item for debate, and it is likely that 144 such an approach would grind on indefinitely. Instead we intend to 145 use a bottom-up approach where we establish the set of services that 146 have already been published in RFCs coming from the Transport Area. 147 This way, much of the discussion about the need to specify these 148 services has already taken place, and it is unnecessary to re-visit 149 those discussions. It is our hope that this approach will lead to 150 identifying a set of service primitives that can be combined to offer 151 a rich set of services to the application. 153 2.2. Exposing Transport Services 155 These Transport Services would be exposed to the application via an 156 API. The definition of such an API and the functionality underneath 157 the API are strictly beyond the scope of this problem statement. 158 However in order to show that this is not just an abstract idea we 159 briefly describe three possible approaches. 161 One approach could be to develop a transport system that fully 162 operates inside the Operating System. This transport system would 163 provide all the defined services for which it can use TCP as a fall- 164 back at the expense of efficiency (e.g., TCP's reliable in-order 165 delivery is a special case of reliable unordered delivery, but it may 166 be less efficient). To test whether a particular transport is 167 available it could take the Happy Eyeballs 168 [I-D.wing-tsvwg-happy-eyeballs-sctp] approach proposed for SCTP -- if 169 the SCTP response arrives too late then the connection just uses TCP 170 and the SCTP association information could be cached so that a future 171 connection request to the same destination IP address can 172 automatically use it. 174 Polyversal TCP [PVTCP] offers another possible approach. This starts 175 by opening a TCP connection and then attempts to establish other 176 paths using different transports. The TCP connection ensures there's 177 always a stable fallback. Having established the initial connection, 178 PVTCP can then use service requests coming through setsockopt() to 179 select the most appropriate transport from the available set. 181 Another approach could be to always rely on UDP only, and develop a 182 whole new transport protocol above UDP which provides all the 183 services, using a single UDP port. Instead of falling back to TCP, 184 this transport system could return an error in case there is no other 185 instance of the transport system available on the other side; the 186 first packets could be used to signal which service is being 187 requested to the other side (e.g., unordered delivery requires the 188 receiving end to be aware of it). 190 3. Why Now? 192 So why do we need to deal with this issue now? There are several 193 answers. Firstly, after several decades of dominance by various 194 flavours of TCP and UDP (plus limited deployment of SCTP [RFC4960]), 195 transport protocols are undergoing significant changes. Recent 196 standards allow for parallel usage of multiple paths (MPTCP [RFC6824] 197 and CMT-SCTP [I-D.tuexen-tsvwg-sctp-multipath]) while other standards 198 allow for scavenger-type traffic LEDBAT [RFC6817]. What sets these 199 apart from e.g. DCCP [RFC4340] is that they have already seen 200 deployment in the wild -- one of the Internet's most popular 201 applications, BitTorrent, uses LEDBAT and MPTCP is already seeing 202 deployment in major operating systems [Bonaventure-Blog]. Meanwhile 203 there is a trend towards tunnelling transports inside UDP -- SCTP 204 over DTLS over UDP is now being shipped with a popular browser in 205 order to support WebRTC [RFC6951][I-D.ietf-tsvwg-sctp-dtls-encaps] 206 while RTMFP [I-D.thornburgh-adobe-rtmfp] and QUIC [QUIC] are recent 207 examples of transport protocols that are implemented over UDP in user 208 space. In a similar vane, Minion [I-D.iyengar-minion-protocol] is a 209 proposal to realise some SCTP-like services with a downwards- 210 compatible extension to TCP. 212 All of a sudden, application developers are faced with a 213 heterogeneous, complex set of protocols to choose from. Every 214 protocol has its pro's and con's, but often the reasons for making a 215 particular choice depend not on the application's preferences but on 216 the environment (e.g., the choice of Minion vs. SCTP would depend on 217 whether SCTP could successfully be used on a given network path). 218 Choosing a protocol that isn't guaranteed to work requires 219 implementing a fall-back method to e.g. TCP, and making the best 220 possible choice at all times may require sophisticated network 221 measurement techniques. The process could be improved by using a 222 cache to learn which protocols previously worked on a path, but this 223 wouldn't always work in a cloud environment where virtual machines 224 can and do migrate between physical nodes. 226 We therefore argue that it is necessary to provide mechanisms that 227 automate the choice and usage of the transport protocol underneath 228 the API that is exposed to applications. As a first step towards 229 such automation, we need to define the services that the transport 230 layer should expose to an application (as opposed to today's typical 231 choice of TCP and UDP). 233 4. Security Considerations 234 {ToDo} While security could be seen as a Transport Service, we prefer 235 to view it as an intrinsic function of the transport layer. In many 236 cases it is essential for the transport connection to be secure (for 237 instance where confidential data is being transferred across the 238 connection). Even where data security is not essential, connection- 239 level security is desirable in all but fully trusted environments. 240 So unless connections actively choose not to be secure, we would 241 expect them to use TLS [RFC5246]. 243 5. IANA Considerations 245 This document makes no request to IANA although in future an IANA 246 register of Transport Services may be required. 248 6. Conclusions 250 After decades of relative stagnation the last few years have seen 251 many new transport protocols being developed and adopted in the wild. 252 This evolution has been driven by the changing needs of application 253 developers and has been enabled by moving transport services into the 254 application or by tunnelling over an underlying UDP connection. 256 Application developers are now faced with a genuine choice of 257 different protocols with no clear mechanism for choosing between 258 them. At the same time, the still-limited deployment of some 259 protocols means that the developer must always provide a fall-back to 260 an alternative transport if they want to guarantee the connection 261 will work. This is not a sustainable state of affairs and we believe 262 that in future a new transport API will be needed that provides the 263 mechanisms to facilitate the choice of transport protocol. The first 264 step towards this is to identify the set of Transport Services that a 265 transport protocol is able to expose to the application. We propose 266 doing this in a bottom-up fashion, starting from the list of services 267 available in transport protocols that are specified in RFCs. 269 7. Contributors and Acknowledgements 271 Many thanks to the many people that have contributed to this effort 272 so far including Michael Tuexen, Arjuna Sathiaseelan, Jon Crowcroft, 273 Marwan Fayed and Bernd Reuther. 275 8. Comments Solicited 276 To be removed by RFC Editor: This draft is the first step towards an 277 IETF BoF on Transport Services. Comments and questions are 278 encouraged and very welcome. They can be addressed to the current 279 mailing list and/or to the authors. 280 We also have a website at 283 9. References 285 9.1. Normative References 287 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 288 August 1980. 290 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 291 793, September 1981. 293 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 294 Jacobson, "RTP: A Transport Protocol for Real-Time 295 Applications", STD 64, RFC 3550, July 2003. 297 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 298 G. Fairhurst, "The Lightweight User Datagram Protocol 299 (UDP-Lite)", RFC 3828, July 2004. 301 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 302 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 304 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 305 4960, September 2007. 307 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 308 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 310 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 311 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 312 December 2012. 314 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 315 "TCP Extensions for Multipath Operation with Multiple 316 Addresses", RFC 6824, January 2013. 318 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 319 Control Transmission Protocol (SCTP) Packets for End-Host 320 to End-Host Communication", RFC 6951, May 2013. 322 9.2. Informative References 324 [Bonaventure-Blog] 325 Bonaventure, O., "Blog Entry: MPTCP used in iOS 7", 326 September 2013. 328 [I-D.dreibholz-tsvwg-sctpsocket-multipath] 329 Dreibholz, T., Becke, M., and H. Adhari, "SCTP Socket API 330 Extensions for Concurrent Multipath Transfer", draft- 331 dreibholz-tsvwg-sctpsocket-multipath-06 (work in 332 progress), July 2013. 334 [I-D.ietf-tsvwg-sctp-dtls-encaps] 335 Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS 336 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 337 dtls-encaps-01 (work in progress), July 2013. 339 [I-D.iyengar-minion-protocol] 340 Jana, J., Cheshire, S., and J. Graessley, "Minion - Wire 341 Protocol", draft-iyengar-minion-protocol-01 (work in 342 progress), July 2013. 344 [I-D.thornburgh-adobe-rtmfp] 345 Thornburgh, M., "Adobe's Secure Real-Time Media Flow 346 Protocol", draft-thornburgh-adobe-rtmfp-10 (work in 347 progress), July 2013. 349 [I-D.tuexen-tsvwg-sctp-multipath] 350 Amer, P., Becke, M., Dreibholz, T., Ekiz, N., Jana, J., 351 Natarajan, P., Stewart, R., and M. Tuexen, "Load Sharing 352 for the Stream Control Transmission Protocol (SCTP)", 353 draft-tuexen-tsvwg-sctp-multipath-07 (work in progress), 354 October 2013. 356 [I-D.wing-tsvwg-happy-eyeballs-sctp] 357 Wing, D. and P. Natarajan, "Happy Eyeballs: Trending 358 Towards Success with SCTP", draft-wing-tsvwg-happy- 359 eyeballs-sctp-02 (work in progress), October 2010. 361 [PVTCP] Nabi, Z., Moncaster, T., Madhavapeddy, A., Hand, S., and 362 J. Crowcroft, "Evolving TCP: how hard can it be?", 363 Proceedings of ACM CoNEXT 2012, December 2012. 365 [QUIC] Roskind, J., "Quick UDP Internet Connections", June 2013. 367 Authors' Addresses 369 Toby Moncaster (editor) 370 University of Cambridge 371 Computer Laboratory 372 J.J. Thomson Avenue 373 Cambridge CB3 0FD 374 UK 376 Phone: +44 1223 763654 377 EMail: toby.moncaster@cl.cam.ac.uk 379 Michael Welzl 380 University of Oslo 381 PO Box 1080 Blindern 382 Oslo N-0316 383 Norway 385 Phone: +47 22 85 24 20 386 EMail: michawe@ifi.uio.no 388 David Ros 389 Telecom Bretagne 390 Rue de la Chataigneraie, CS 17607 391 35576 Cesson Sevigne cedex 392 France 394 Phone: +33 2 99 12 70 46 395 EMail: david.ros@telecom-bretagne.eu