Problem Statement: Why the IETF Needs Defined Transport Services

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

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at


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