Skip to main content

Problem Statement: Why the IETF Needs Defined Transport Services

Document Type Expired Internet-Draft (individual)
Expired & archived
Authors Toby Moncaster , Jon Crowcroft , Michael Welzl , David Ros , Michael Tüxen
Last updated 2014-06-07 (Latest revision 2013-12-04)
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


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


Toby Moncaster
Jon Crowcroft
Michael Welzl
David Ros
Michael Tüxen

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)