One document matched: draft-moncaster-tsvwg-transport-services-00.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-00"
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="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>
<date day="21" month="October" 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.
</t>
<t> 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.
</t>
</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 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. </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 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.
</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>{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 <xref target="RFC5246"/>.
</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
Michael Tuexen, Arjuna Sathiaseelan, Jon Crowcroft, Marwan Fayed and Bernd Reuther. </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:59:34 |