Transport Area                                         T. Moncaster, Ed.
Internet-Draft                                              J. Crowcroft
Intended status: Informational                   University of Cambridge
Expires: June 7, 2014                                           M. Welzl
                                                      University of Oslo
                                                                  D. Ros
                                                        Telecom Bretagne
                                                               M. Tuexen
                                        Muenster Univ. of Appl. Sciences
                                                        December 4, 2013

    Problem Statement: Why the IETF Needs Defined Transport Services


   The IETF has defined a wide range of transport protocols over the
   past three decades.  However, the majority of these have failed to
   find traction within the Internet.  This has left developers with
   little choice but to use TCP and UDP for most applications.  In many
   cases the developer isn't interested in which transport protocol they
   should use.  Rather they are interested in the set of services that
   the protocol provides to their application.  TCP provides a very rich
   set of transport services, but offers no flexibility over which
   services can be used.  By contrast, UDP provides a minimal set of

   As a consequence many developers have begun to write application-
   level transport protocols that operate on top of UDP and offer them
   some of the flexibility they are looking for.  We believe that this
   highlights a real problem: applications would like to be able to
   specify the services they receive from the transport protocol, but
   currently transport protocols are not defined in this fashion.  There
   is an additional problem relating to how to ensure new protocols are
   able to be adopted within the Internet, but that is beyond the scope
   of this problem statement.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

Moncaster, et al.         Expires June 7, 2014                  [Page 1]

Internet-Draft             Transport Services              December 2013

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 7, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Changes in This Version (to be removed by RFC Editor) . .   3
   2.  Transport Services  . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Identifying Transport Services  . . . . . . . . . . . . .   4
     2.2.  Exposing Transport Services . . . . . . . . . . . . . . .   4
   3.  Why Now?  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Contributors and Acknowledgements . . . . . . . . . . . . . .   7
   8.  Comments Solicited  . . . . . . . . . . . . . . . . . . . . .   7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The IETF has defined a wide array of transport protocols including
   UDP [RFC0768], TCP [RFC0793], SCTP [RFC4960], UDP-Lite [RFC3828],
   DCCP [RFC4340] and MPTCP [RFC6824].  In most cases new protocols have
   been defined because the IETF has established that there is a need
   for a set of behaviours than cannot be offered by any existing
   transport protocol.

Moncaster, et al.         Expires June 7, 2014                  [Page 2]

Internet-Draft             Transport Services              December 2013

   However, for an application programmer, using protocols other than
   TCP or UDP can be hard: not all protocols are available everywhere,
   hence a fall-back solution to TCP or UDP must be implemented.  Some
   protocols provide the same services in different ways.  Layering
   decisions must be made (e.g. should a protocol be used natively or
   over UDP?).  Because of these complications, programmers often resort
   to either using TCP (even if there is a mismatch between the services
   provided by TCP and the services needed by the application) or
   implementing their own customised solution over UDP, and the
   opportunity of benefiting from other transport protocols is lost.
   Since all these protocols were developed to provide services that
   solve particular problems, the inability of applications to make use
   of them is in itself a problem.  Implementing a new solution e.g.
   over UDP also means re-inventing the wheel (or, rather, re-
   implementing the code) for a number of general network functions such
   as methods to interoperate through NATs and PMTUD.

   We believe this mismatch between the application layer and transport
   layer can be addressed in a simple fashion.  If an API allowed
   applications to request transport services without specifying the
   protocol, the transport system underneath could automatically try to
   make the best of its available resources.  It could use available
   transport protocols in a way that is most beneficial for applications
   and without the application needing to worry about problems with
   middlebox traversal.  Adopting this approach could give more freedom
   for diversification to designers of Operating Systems.

1.1.  Changes in This Version (to be removed by RFC Editor)

   From draft-moncaster-tsvwg-transport-services-00 to -01:  Editorial
      corrections and clarifications including:

      *  Updated Section 2.1 to highlight that we will take a hybrid
         approach to identifying Transport Services, both top down (by
         examining existing APIs) and bottom up (by looking at existing
         transport protocols).

      *  Updated Section 2.2 to commit to delivering at least one
         example API for this work.

      *  Replaced Section 4.  The new version makes it clear that we
         will preserve the status quo where the transport may or may not
         choose to implement security.

2.  Transport Services

   The transport layer provides many services both to the end
   application (e.g. multiplexing, flow control, ordering, reliability)

Moncaster, et al.         Expires June 7, 2014                  [Page 3]

Internet-Draft             Transport Services              December 2013

   and to the network (e.g. congestion control).  For the purposes of
   this document we define Transport Services as follows:

   o  A Transport Service is any service provided by the transport layer
      that can only be correctly implemented with information from the

   The key word here is "information" -- many existing transport
   protocols function perfectly adequately because the choice of
   protocol implicitly includes information about the desired transport
   capabilities.  For instance the choice of TCP implies a desire for
   reliable, in-order data delivery.  However we think that such
   implicit information is not always sufficient.  The rest of this
   section explains how we propose to identify Transport Services and
   how those services might then be exposed to the application.

2.1.  Identifying Transport Services

   One of the key aspects of this work is how to identify which
   Transport Services should actually be supported.  We are taking a
   two-pronged approach.  Rather than trying to identify every possible
   service that popular applications might need, we will survey a given
   set of common APIs that applications use to communicate across the
   network.  We will complement this with a bottom-up approach where we
   establish the set of services that have already been published in
   RFCs coming from the Transport Area.  This way, much of the
   discussion about the need to specify these services has already taken
   place, and it is unnecessary to re-visit those discussions.  It is
   our hope that this approach will lead to identifying a set of service
   primitives that can be combined to offer a rich set of services to
   the application.

2.2.  Exposing Transport Services

   These Transport Services would be exposed to the application via an
   API.  The definition of such an API and the functionality underneath
   the API are beyond the scope of this problem statement.  We briefly
   describe three possible approaches below.

   One approach could be to develop a transport system that fully
   operates inside the Operating System.  This transport system would
   provide all the defined services for which it can use TCP as a fall-
   back at the expense of efficiency (e.g., TCP's reliable in-order
   delivery is a special case of reliable unordered delivery, but it may
   be less efficient).  To test whether a particular transport is
   available it could take the Happy Eyeballs
   [I-D.wing-tsvwg-happy-eyeballs-sctp] approach proposed for SCTP -- if
   the SCTP response arrives too late then the connection just uses TCP

Moncaster, et al.         Expires June 7, 2014                  [Page 4]

Internet-Draft             Transport Services              December 2013

   and the SCTP association information could be cached so that a future
   connection request to the same destination IP address can
   automatically use it.

   Polyversal TCP [PVTCP] offers another possible approach.  This starts
   by opening a TCP connection and then attempts to establish other
   paths using different transports.  The TCP connection ensures there's
   always a stable fallback.  Having established the initial connection,
   PVTCP can then use service requests coming through setsockopt() to
   select the most appropriate transport from the available set.

   Another approach could be to always rely on UDP only, and develop a
   whole new transport protocol above UDP which provides all the
   services, using a single UDP port.  Instead of falling back to TCP,
   this transport system could return an error in case there is no other
   instance of the transport system available on the other side; the
   first packets could be used to signal which service is being
   requested to the other side (e.g., unordered delivery requires the
   receiving end to be aware of it).

3.  Why Now?

   So why do we need to deal with this issue now?  There are several
   answers.  Firstly, after several decades of dominance by various
   flavours of TCP and UDP (plus limited deployment of SCTP [RFC4960]),
   transport protocols are undergoing significant changes.  Recent
   standards allow for parallel usage of multiple paths (MPTCP [RFC6824]
   and CMT-SCTP [I-D.tuexen-tsvwg-sctp-multipath]) while other standards
   allow for scavenger-type traffic (LEDBAT [RFC6817]).  What sets these
   apart from e.g. DCCP [RFC4340] is that they have already seen
   deployment in the wild -- one of the Internet's most popular
   applications, BitTorrent, uses LEDBAT and MPTCP is already seeing
   deployment in major operating systems [Bonaventure-Blog].  Meanwhile
   there is a trend towards tunnelling transports inside UDP -- SCTP
   over DTLS over UDP is now being shipped with a popular browser in
   order to support WebRTC [RFC6951][I-D.ietf-tsvwg-sctp-dtls-encaps]
   while RTMFP [I-D.thornburgh-adobe-rtmfp] and QUIC [QUIC] are recent
   examples of transport protocols that are implemented over UDP in user
   space.  In a similar vane, Minion [I-D.iyengar-minion-protocol] is a
   proposal to realise some SCTP-like services with a downwards-
   compatible extension to TCP.

   All of a sudden, application developers are faced with a
   heterogeneous, complex set of protocols to choose from.  Every
   protocol has its pro's and con's, but often the reasons for making a
   particular choice depend not on the application's preferences but on
   the environment (e.g., the choice of Minion vs. SCTP would depend on
   whether SCTP could successfully be used on a given network path).

Moncaster, et al.         Expires June 7, 2014                  [Page 5]

Internet-Draft             Transport Services              December 2013

   Choosing a protocol that isn't guaranteed to work requires
   implementing a fall-back method to e.g. TCP, and making the best
   possible choice at all times may require sophisticated network
   measurement techniques.  The process could be improved by using a
   cache to learn which protocols previously worked on a path, but this
   wouldn't always work in a cloud environment where virtual machines
   can and do migrate between physical nodes.

   We therefore argue that it is necessary to provide mechanisms that
   automate the choice and usage of the transport protocol underneath
   the API that is exposed to applications.  As a first step towards
   such automation, we need to define the services that the transport
   layer should expose to an application (as opposed to today's typical
   choice of TCP and UDP).

4.  Security Considerations

   Whether or not to enable TLS[RFC5246] is currently left up to
   individual protocol implementations to decide.  While there is some
   debate about whether this is correct we have chosen to keep the
   status quo.

5.  IANA Considerations

   This document makes no request to IANA although in future an IANA
   register of Transport Services may be required.

6.  Conclusions

   After decades of relative stagnation the last few years have seen
   many new transport protocols being developed and adopted in the wild.
   This evolution has been driven by the changing needs of application
   developers and has been enabled by moving transport services into the
   application or by tunnelling over an underlying UDP connection.

   Application developers are now faced with a genuine choice of
   different protocols with no clear mechanism for choosing between
   them.  At the same time, the still-limited deployment of some
   protocols means that the developer must always provide a fall-back to
   an alternative transport if they want to guarantee the connection
   will work.  This is not a sustainable state of affairs and we believe
   that in future a new transport API will be needed that provides the
   mechanisms to facilitate the choice of transport protocol.  The first
   step towards this is to identify the set of Transport Services that a
   transport protocol is able to expose to the application.  We propose
   doing this in a bottom-up fashion, starting from the list of services
   available in transport protocols that are specified in RFCs.

Moncaster, et al.         Expires June 7, 2014                  [Page 6]

Internet-Draft             Transport Services              December 2013

7.  Contributors and Acknowledgements

   Many thanks to the many people that have contributed to this effort
   so far including Arjuna Sathiaseelan, Jon Crowcroft, Marwan Fayed and
   Bernd Reuther among many others.

   D. Ros and M. Welzl were part-funded by the European Community under
   its Seventh Framework Programme through the Reducing Internet
   Transport Latency (RITE) project (ICT-317700).  T. Moncaster and J.
   Crowcroft are part-funded by the European Union's Seventh Framework
   Programme FP7/2007-2013 under the Trilogy 2 project, grant agreement
   no. 317756.

8.  Comments Solicited

   To be removed by RFC Editor: This draft is the first step towards an
   IETF BoF on Transport Services.  Comments and questions are
   encouraged and very welcome.  They can be addressed to the current
   mailing list <> and/or to the authors.
   We also have a website at <

9.  References

9.1.  Normative References

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, September 1981.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC3828]  Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
              G. Fairhurst, "The Lightweight User Datagram Protocol
              (UDP-Lite)", RFC 3828, July 2004.

   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
              Congestion Control Protocol (DCCP)", RFC 4340, March 2006.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol", RFC
              4960, September 2007.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

Moncaster, et al.         Expires June 7, 2014                  [Page 7]

Internet-Draft             Transport Services              December 2013

   [RFC6817]  Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
              "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
              December 2012.

   [RFC6824]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
              "TCP Extensions for Multipath Operation with Multiple
              Addresses", RFC 6824, January 2013.

   [RFC6951]  Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
              Control Transmission Protocol (SCTP) Packets for End-Host
              to End-Host Communication", RFC 6951, May 2013.

9.2.  Informative References

              Bonaventure, O., "Blog Entry: MPTCP used in iOS 7",
              September 2013.

              Dreibholz, T., Becke, M., and H. Adhari, "SCTP Socket API
              Extensions for Concurrent Multipath Transfer", draft-
              dreibholz-tsvwg-sctpsocket-multipath-06 (work in
              progress), July 2013.

              Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS
              Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-
              dtls-encaps-02 (work in progress), October 2013.

              Jana, J., Cheshire, S., and J. Graessley, "Minion - Wire
              Protocol", draft-iyengar-minion-protocol-02 (work in
              progress), October 2013.

              Thornburgh, M., "Adobe's Secure Real-Time Media Flow
              Protocol", draft-thornburgh-adobe-rtmfp-10 (work in
              progress), July 2013.

              Amer, P., Becke, M., Dreibholz, T., Ekiz, N., Jana, J.,
              Natarajan, P., Stewart, R., and M. Tuexen, "Load Sharing
              for the Stream Control Transmission Protocol (SCTP)",
              draft-tuexen-tsvwg-sctp-multipath-07 (work in progress),
              October 2013.


Moncaster, et al.         Expires June 7, 2014                  [Page 8]

Internet-Draft             Transport Services              December 2013

              Wing, D. and P. Natarajan, "Happy Eyeballs: Trending
              Towards Success with SCTP", draft-wing-tsvwg-happy-
              eyeballs-sctp-02 (work in progress), October 2010.

   [PVTCP]    Nabi, Z., Moncaster, T., Madhavapeddy, A., Hand, S., and
              J. Crowcroft, "Evolving TCP: how hard can it be?",
              Proceedings of ACM CoNEXT 2012, December 2012.

   [QUIC]     Roskind, J., "Quick UDP Internet Connections", June 2013.

Authors' Addresses

   Toby Moncaster (editor)
   University of Cambridge
   Computer Laboratory
   J.J. Thomson Avenue
   Cambridge  CB3 0FD

   Phone: +44 1223 763654

   Jon Crowcroft
   University of Cambridge
   Computer Laboratory
   J.J. Thomson Avenue
   Cambridge  CB3 0FD

   Phone: +44 1223 763633

   Michael Welzl
   University of Oslo
   PO Box 1080 Blindern
   Oslo  N-0316

   Phone: +47 22 85 24 20

Moncaster, et al.         Expires June 7, 2014                  [Page 9]

Internet-Draft             Transport Services              December 2013

   David Ros
   Telecom Bretagne
   Rue de la Chataigneraie, CS 17607
   35576 Cesson Sevigne cedex

   Phone: +33 2 99 12 70 46

   Michael Tuexen
   Muenster University of Applied Sciences
   Stegerwaldstrasse 39
   Steinfurt  48565


Moncaster, et al.         Expires June 7, 2014                 [Page 10]