One document matched: draft-moncaster-tsvwg-transport-services-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="yes"?>
<?rfc rfcedstyle="yes"?>
<rfc category="info" docName="draft-moncaster-tsvwg-transport-services-01"
ipr="trust200902">
<front>
<title abbrev="Transport Services">Problem Statement: Why the IETF Needs Defined Transport Services </title>
<author fullname="Toby Moncaster" initials="T." surname="Moncaster" role="editor">
<organization>University of Cambridge</organization>
<address>
<postal>
<street>Computer Laboratory</street>
<street>J.J. Thomson Avenue</street>
<city>Cambridge</city>
<code>CB3 0FD</code>
<country>UK</country>
</postal>
<phone>+44 1223 763654</phone>
<email>toby.moncaster@cl.cam.ac.uk</email>
</address>
</author>
<author fullname="Jon Crowcroft" initials="J." surname="Crowcroft" >
<organization>University of Cambridge</organization>
<address>
<postal>
<street>Computer Laboratory</street>
<street>J.J. Thomson Avenue</street>
<city>Cambridge</city>
<code>CB3 0FD</code>
<country>UK</country>
</postal>
<phone>+44 1223 763633</phone>
<email>jon.crowcroft@cl.cam.ac.uk</email>
</address>
</author>
<author fullname="Michael Welzl" initials="M.W." surname="Welzl">
<organization>University of Oslo</organization>
<address>
<postal>
<street>PO Box 1080 Blindern</street>
<!-- Reorder these if your country does things differently -->
<code>N-0316</code>
<city>Oslo</city>
<region></region>
<country>Norway</country>
</postal>
<phone>+47 22 85 24 20</phone>
<email>michawe@ifi.uio.no</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="David Ros" initials="D." surname="Ros">
<organization>Telecom Bretagne</organization>
<address>
<postal>
<street>Rue de la Chataigneraie, CS 17607</street>
<city>35576 Cesson Sevigne cedex</city>
<code></code>
<region></region>
<country>France</country>
</postal>
<phone>+33 2 99 12 70 46</phone>
<email>david.ros@telecom-bretagne.eu</email>
</address>
</author>
<author initials='M.' surname='Tuexen' fullname='Michael Tuexen'>
<organization abbrev='Muenster Univ. of Appl. Sciences'>
Muenster University of Applied Sciences</organization>
<address>
<postal>
<street>Stegerwaldstrasse 39</street>
<code>48565</code>
<city> Steinfurt</city>
<country>DE</country>
</postal>
<email>tuexen@fh-muenster.de</email>
</address>
</author>
<date day="4" month="December" year="2013" />
<area>Transport</area>
<workgroup>Transport Area</workgroup>
<keyword>Transport Services</keyword>
<keyword>Congestion Control</keyword>
<keyword>Signalling</keyword>
<keyword>Protocol</keyword>
<abstract>
<t>
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 services.</t>
<t>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.
</t>
</abstract>
</front>
<middle>
<section anchor="TranServ_Intro" title="Introduction">
<t>The IETF has defined a wide array of transport protocols
including <xref target="RFC0768">UDP</xref>, <xref target="RFC0793">TCP</xref>,
<xref target="RFC4960">SCTP</xref>, <xref target="RFC3828">UDP-Lite</xref>, <xref
target="RFC4340">DCCP</xref> and
<xref target="RFC6824">MPTCP</xref>. 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.
</t>
<t>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.
</t>
<t> 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.
</t>
<section anchor="TranServ_Changes"
title="Changes in This Version (to be removed by RFC Editor)">
<t><list style="hanging">
<t
hangText="From draft-moncaster-tsvwg-transport-services-00 to -01:">
Editorial corrections and clarifications including:
<list style="symbols">
<t>Updated <xref target="TranServ_What"/> 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).</t>
<t> Updated <xref target="TranServ_How"/> to commit to
delivering at least one example API for this work. </t>
<t>Replaced <xref target="TranServ_Security"/>. The new
version makes it clear that we will preserve the status quo where the
transport may or may not choose to implement security.</t>
</list></t>
</list></t>
</section>
</section>
<section anchor="TranServ_Need" title="Transport Services">
<t>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:
<list style="symbols">
<t>A Transport Service is any service provided by the transport layer that can only be correctly implemented with information from the application.
</t>
</list>
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.
</t>
<section anchor="TranServ_What" title="Identifying Transport Services">
<t>
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. </t>
</section>
<section anchor="TranServ_How" title="Exposing Transport Services">
<t> 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.
</t><t>
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 <xref target="I-D.wing-tsvwg-happy-eyeballs-sctp">Happy Eyeballs</xref> 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.
</t>
<t>
<xref target="PVTCP">Polyversal TCP</xref> 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.
</t>
<t>
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).
</t>
</section>
</section>
<section anchor="TranServ_WhyNow" title="Why Now?">
<t>
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 <xref target="RFC4960">SCTP</xref>), transport protocols are undergoing significant changes. Recent standards allow for parallel usage of multiple paths (<xref target="RFC6824">MPTCP</xref> and <xref target="I-D.tuexen-tsvwg-sctp-multipath">CMT-SCTP</xref>) while other standards allow for scavenger-type traffic (<xref target="RFC6817">LEDBAT</xref>). What sets these apart from e.g. <xref target="RFC4340">DCCP</xref> 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 <xref target="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 <xref target="RFC6951"/><xref target="I-D.ietf-tsvwg-sctp-dtls-encaps"/> while <xref target="I-D.thornburgh-adobe-rtmfp">RTMFP</xref> and <xref target="QUIC">QUIC</xref> are recent examples of transport protocols that are implemented over UDP in user space. In a similar vane, <xref target="I-D.iyengar-minion-protocol">Minion</xref> is a proposal to realise some SCTP-like services with a downwards-compatible extension to TCP.
</t>
<t>
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. </t>
<t>
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).
</t>
</section>
<section anchor="TranServ_Security" title="Security Considerations">
<t>Whether or not to enable TLS<xref target="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.
</t>
</section>
<section anchor="TranServ_IANA" title="IANA Considerations">
<t>This document makes no request to IANA although in future an IANA register of Transport Services may be required.</t>
</section>
<section anchor="TranServ_Conclusions" title="Conclusions">
<t>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.
</t>
<t>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.
</t>
</section>
<section anchor="TranServ_Acknowledgements" title="Contributors and Acknowledgements">
<t>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. </t>
<t>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.</t>
</section>
<section anchor="pcn3in1_Comments_Solicited" title="Comments Solicited">
<t>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
<transport-services@ifi.uio.no> and/or to the authors. We also have
a website at <https://sites.google.com/site/transportprotocolservices/></t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.0768" ?>
<?rfc include="reference.RFC.0793" ?>
<?rfc include="reference.RFC.4960" ?>
<?rfc include="reference.RFC.3550" ?>
<?rfc include="reference.RFC.3828" ?>
<?rfc include="reference.RFC.4340" ?>
<?rfc include="reference.RFC.5246" ?>
<?rfc include="reference.RFC.6817" ?>
<?rfc include="reference.RFC.6824" ?>
<?rfc include="reference.RFC.6951" ?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.dreibholz-tsvwg-sctpsocket-multipath" ?>
<?rfc include="reference.I-D.thornburgh-adobe-rtmfp" ?>
<?rfc include="reference.I-D.iyengar-minion-protocol" ?>
<?rfc include="reference.I-D.wing-tsvwg-happy-eyeballs-sctp" ?>
<?rfc include="reference.I-D.tuexen-tsvwg-sctp-multipath" ?>
<?rfc include="reference.I-D.ietf-tsvwg-sctp-dtls-encaps" ?>
<reference anchor='Bonaventure-Blog'>
<front>
<title>Blog Entry: MPTCP used in iOS 7</title>
<author initials='O.' surname='Bonaventure'
fullname='Olivier Bonaventure'>
<organization abbrev='UCL-Be'>
Université Catholique de Louvain </organization>
</author>
<date month='September' year='2013' />
</front>
<format type='HTML'
target='http://perso.uclouvain.be/olivier.bonaventure/blog/html/2013/09/18/mptcp.html' />
</reference>
<reference anchor='QUIC'>
<front>
<title>Quick UDP Internet Connections</title>
<author initials='J.' surname='Roskind'
fullname='Jim Roskind'>
<organization abbrev='Google'>
Google Inc.</organization>
</author>
<date month='June' year='2013' />
</front>
<format type='HTML'
target=' https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit' />
</reference>
<reference anchor='PVTCP'>
<front>
<title>Evolving TCP: how hard can it be?</title>
<author initials='Z.' surname='Nabi'
fullname='Zubair Nabi'>
</author>
<author initials="T." surname="Moncaster" fullname="Toby Moncaster"> </author>
<author initials="A." surname="Madhavapeddy" fullname="Anil Madhavapeddy"> </author>
<author initials="S." surname="Hand" fullname="Steve Hand"> </author>
<author initials="J." surname="Crowcroft" fullname="Jon Crowcroft"> </author>
<date month='December' year='2012' />
</front>
<seriesInfo name='Proceedings of ACM CoNEXT' value='2012' />
<format type='PDF'
target='http://anil.recoil.org/papers/2012-conext-pvtcp-position.pdf' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:50:43 |