Skip to main content

Problem Statement: Why the IETF Needs Defined Transport Services

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Toby Moncaster , Michael Welzl , David Ros
Last updated 2013-10-18
RFC stream (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
Transport Area                                         T. Moncaster, Ed.
Internet-Draft                                   University of Cambridge
Intended status: Informational                                  M. Welzl
Expires: April 21, 2014                               University of Oslo
                                                                  D. Ros
                                                        Telecom Bretagne
                                                        October 18, 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 April 21, 2014                 [Page 1]
Internet-Draft             Transport Services               October 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 April 21, 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
   2.  Transport Services  . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Identifying Transport Services  . . . . . . . . . . . . .   3
     2.2.  Exposing Transport Services . . . . . . . . . . . . . . .   4
   3.  Why Now?  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Contributors and Acknowledgements . . . . . . . . . . . . . .   6
   8.  Comments Solicited  . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7

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 April 21, 2014                 [Page 2]
Internet-Draft             Transport Services               October 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.

   We believe this mismatch between the application layer and transport
   layer can be addressed in a simple fashion.  If the socket interface
   provided a way for applications to request transport services without
   specifying the protocol, a transport system underneath the socket API
   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.

2.  Transport Services

   The transport layer provides many services both to the end
   application (e.g. multiplexing, flow control, ordering, reliability)
   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

Moncaster, et al.        Expires April 21, 2014                 [Page 3]
Internet-Draft             Transport Services               October 2013

   One of the key aspects of this work is how to actually identify which
   Transport Services should be supported.  The top-down approach to
   this would be to identify every possible service that popular
   applications might need.  The problem with this method is that every
   potential service becomes an item for debate, and it is likely that
   such an approach would grind on indefinitely.  Instead we intend to
   use 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 strictly beyond the scope of this problem statement.
   However in order to show that this is not just an abstract idea we
   briefly describe three possible approaches.

   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
   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

Moncaster, et al.        Expires April 21, 2014                 [Page 4]
Internet-Draft             Transport Services               October 2013

   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).
   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

Moncaster, et al.        Expires April 21, 2014                 [Page 5]
Internet-Draft             Transport Services               October 2013

   {ToDo} While security could be seen as a Transport Service, we prefer
   to view it as an intrinsic function of the transport layer.  In many
   cases it is essential for the transport connection to be secure (for
   instance where confidential data is being transferred across the
   connection).  Even where data security is not essential, connection-
   level security is desirable in all but fully trusted environments.
   So unless connections actively choose not to be secure, we would
   expect them to use TLS [RFC5246].

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.

7.  Contributors and Acknowledgements

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

8.  Comments Solicited

Moncaster, et al.        Expires April 21, 2014                 [Page 6]
Internet-Draft             Transport Services               October 2013

   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.

   [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

Moncaster, et al.        Expires April 21, 2014                 [Page 7]
Internet-Draft             Transport Services               October 2013

              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.

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

              Jana, J., Cheshire, S., and J. Graessley, "Minion - Wire
              Protocol", draft-iyengar-minion-protocol-01 (work in
              progress), July 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.

              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.

Moncaster, et al.        Expires April 21, 2014                 [Page 8]
Internet-Draft             Transport Services               October 2013

Authors' Addresses

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

   Phone: +44 1223 763654

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

   Phone: +47 22 85 24 20

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

   Phone: +33 2 99 12 70 46

Moncaster, et al.        Expires April 21, 2014                 [Page 9]