One document matched: draft-fairhurst-taps-transports-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml2rfc.ietf.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!--<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
-->
<!-- http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml-->
<!ENTITY RFC2309 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2309.xml">
<!ENTITY RFC2481 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2481.xml">
<!ENTITY RFC2884 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2884.xml">
<!ENTITY RFC3168 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml">
<!ENTITY RFC3649 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3649.xml">
<!ENTITY RFC3742 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3742.xml">
<!ENTITY RFC3758 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3758.xml">
<!ENTITY RFC4340 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4340.xml">
<!ENTITY RFC5562 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5562.xml">
<!ENTITY RFC5670 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5670.xml">
<!ENTITY RFC5696 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5696.xml">
<!ENTITY RFC6679 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6679.xml">
<!ENTITY RFC6789 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6789.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml2rfc.ietf.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="no"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<rfc category="info" docName="draft-fairhurst-taps-transports-00"
ipr="trust200902">
<!-- noModificationTrust200902 noDerivativesTrust200902 pre5378Trust200902">-->
<!-- updates="6298"> -->
<!-- ipr="full3978"> -->
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<!-- <title abbrev="Abbreviated Title">Coupled congestion control</title> -->
<title abbrev="TAPS transport protocols and CC mechanisms">Services
provided by IETF transport protocols and congestion control
mechanisms</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Godred Fairhurst" initials="G." surname="Fairhurst">
<organization>University of Aberdeen</organization>
<address>
<postal>
<street>School of Engineering, Fraser Noble Building</street>
<!-- Reorder these if your country does things differently -->
<code>AB24 3UE</code>
<city>Aberdeen</city>
<region></region>
<country>UK</country>
</postal>
<phone></phone>
<email>gorry@erg.abdn.ac.uk</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Brian Trammell" initials="B." surname="Trammell">
<organization>ETH Zurich</organization>
<address>
<postal>
<street>Gloriastrasse 35</street>
<!-- Reorder these if your country does things differently -->
<code>8092</code>
<city>Zurich</city>
<region></region>
<country>CH</country>
</postal>
<phone></phone>
<email>ietf@trammell.ch</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date day="27" month="October" year="2014" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Transport</area>
<workgroup></workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>sctp, tcp</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document describes services provided by existing IETF protocols
and congestion control mechanisms. It is designed to help application
and network stack programmers and to inform the work of the IETF TAPS
Working Group.</t>
</abstract>
</front>
<middle>
<!-- <section title="Definitions" anchor='sec-def'>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
<t><list style="hanging" hangIndent="6">
<t hangText="Wha'ever:">
<vspace />
Wha'ever is short for Whatever.</t>
</list></t>
</section>
-->
<section anchor="sec-intro" title="Introduction">
<t>Most Internet applications make use of the Transport Services
provided by TCP (a reliable, in-order stream protocol) or UDP (an
unreliable datagram protocol). We use the term "Transport Service" to
mean an end-to-end facility provided by the transport layer. That
service can only be provided correctly if information is supplied from
the application. The application may determine the information to be
supplied at design time, compile time, or run time and may include
guidance on whether an aspect of the service is required, a preference
by the application, or something in between. Examples of Transport
service facilities are reliable delivery, ordered delivery, content
privacy to in-path devices, integrity protection, and minimal
latency.</t>
<t>Transport protocols such as SCTP, DCCP, MPTCP, UDP and UDP-Lite have
been defined at the transport layer.</t>
<t>In addition, a transport service may be built on top of these
transport protocols, using a fraemwork such as WebSockets, or RTP.
Service built on top of UDP or UDP-Lite typically also need to specify a
congestion control mechanism, such as TFRC or the LEDBAT congestion
control mechanism. This extends the set of available Transport Services
beyond those provided to applications by TCP and UDP.</t>
<t>Transport services can aslo be differentiated by the services they
provide: for instance, SCTP offers a message-based service that does not
suffer head-of-line blocking when used with multiple stream, because it
can accept blocks of data out of order, UDP-Lite provides partial
integrity protection when used over link-layer services that can support
this, and LEDBAT can provide low-priority "scavenger" communication.</t>
</section>
<section title="Terminology">
<t>This section presents the terminology used in this document.</t>
<t>[EDITOR'S NOTE: Terminology to be discussed in Honolulu. We need to
determine what a "service" as used by the IETF, as opposed to a "service
component", "property", an "aspect", "dimension", etc.]</t>
</section>
<section title="Transport Protocols">
<t>This section provides a list of known IETF transport protocol and
transport protocol frameworks.</t>
<t>[EDITOR'S NOTE: combine these tables into one? Also, reorder them to
match ths sections below.]</t>
<figure>
<artwork><![CDATA[+---------+-------------------------------------+------+---------------------+
| Section | Benefit | Setup| Mode |
+---------+-------------------------------------+------+---------------------+
| 3.1 | Transmission Control Protocol (TCP) | CO | Unicast |
| 3.1.1 | Multipath-TCP (MPTCP) | CO | Unicast |
| 3.2 | SCTP | CO | Unicast |
| 3.2.1 | SCTP-PR | CO | Unicast |
| 3.3 | User Datagram Protocol (UDP) | DG | Unicast/Multicst |
| 3.4 | UDP-Lite | DG | Unicast/Multicst |
| 3.5 | DCCP | CO | Unicast |
| 3.X | More as needed | | |
+---------+-------------------------------------+------+---------------------+
Table 1: Key IETF Transport Protocol - by cmmunication mode]]></artwork>
</figure>
<figure>
<artwork><![CDATA[+---------+-------------------------------------+------+---------------------+
| Section | Benefit | Style| Reliability |
+---------+-------------------------------------+------+---------------------+
| 3.1 | Transmission Control Protocol (TCP) | Str | Ordered Byte Stream |
| 3.1.1 | Multipath-TCP (MPTCP) | Str | Ordered Byte Stream |
| 3.2 | SCTP | Mess | Message Streams |
| 3.2.1 | SCTP-PR | Mess | Partial M Streams |
| 3.3 | User Datagram Protocol (UDP) | Mess | Datagram Message |
| 3.4 | UDP-Lite | Mess | Error Tolerant DG |
| 3.5 | DCCP | Mess | Unrel Message Stream|
| 3.X | More as needed | | |
+---------+-------------------------------------+------+---------------------+
Table 2: Key IETF Transport Protocol - by reliability]]></artwork>
</figure>
<t></t>
<t>"Setup" defines whether the protocol performs a connection-oriented
protocol handshake prior o communication or is datagram based. This
provides reliable negotiation of options, including negotiation of a
suitable congestion control mechanism.This property can impact the
ability of the protocol to traverse firewalls.</t>
<figure>
<artwork><![CDATA[+---------+-------------------------------------+----------------------------+
| Section | Benefit | Congestion Control |
+---------+-------------------------------------+----------------------------+
| 3.1 | Transmission Control Protocol (TCP) | Yes |
| 3.1.1 | Multipath-TCP (MPTCP) | Yes (Multipath) |
| 3.2 | SCTP | Yes |
| 3.2.1 | SCTP-PR | Yes |
| 3.3 | User Datagram Protocol (UDP) | At application layer |
| 3.4 | UDP-Lite | At application layer |
| 3.5 | DCCP | Yes, Various CCIDs defined |
| 3.X | More as needed | |
+---------+-------------------------------------+----------------------------+
Table 3: Key IETF Transport Protocol - by congestion control
]]></artwork>
</figure>
<t></t>
<t>Some other protocol frameworks that may potentially be considered for
inclusion in future versions of this document. Examples are:<list
style="symbols">
<t>Multicast - RMT</t>
<t>RTP-based methods</t>
<t>HTTP-based methods</t>
<t>TLS</t>
<t>DTLS</t>
</list></t>
<t>The following subsections describes each of these transports.</t>
<section title="Transport Control Protocol (TCP)">
<t>TCP provides a bidirectional byte-oriented stream over a
connection-oriented protocol. The protocol and API use the byte-stream
model.</t>
<t>[EDITOR'S NOTE: Describe the aspects(?) of TCP: reliable,
connection-oriented, congestion-controlled, single-stream-oriented,
non-boundary-preserving... Note that we want to describe the
characteristics of the SOCK_STREAM API as well as just the wire
protocol.]</t>
<section title="Multipath TCP (MPTCP)">
<t>[EDITOR'S NOTE: aspects of MPTCP beyond TCP.]</t>
</section>
</section>
<section title="Stream Control Transmission Protocol (SCTP)">
<t>This section will describe SCTP.</t>
<t>SCTP provides a bidirectional set of logical unicast streams over
one a connection-oriented protocol. The protocol and API use messages,
rather than a byte-stream. Each stream of messages is independently
managed, therefore retransmission does not hold back data sent using
other logical streams</t>
<section title="Partial Reliability SCTP (PR-CTP)">
<t>SCTP-PR [RFC3758] is a variant of SCTP that provides partial
reliability.</t>
</section>
</section>
<section title="User Datagram Protocol (UDP)">
<t>The User Datagram Protocol (UDP) provides a unidirectional minimal
message-passing transport that has no inherent congestion control
mechanisms. The service may be multicast and/or unicast.</t>
<t>[EDITOR'S NOTE: Describe the aspects(?) of UDP: unreliable,
congestion control to be applied above the transport,
datagram-oriented, connectionless, boundary-preserving... Note that we
want to describe the characteristics of the SOCK_DGRAM API as well as
just the wire protocol.]</t>
<t>Using UDP robustly requires each application to implement a raft of
functions (mostly re-inventing or adaptng mechansism already found in
TCP, SCTP and DCCP). [EDITOR'S NOTE: reference RFC 5405/bis ]</t>
</section>
<section title="UDP-Lite">
<t>A special class of applications can derive benefit from having
partially-damaged payloads delivered, rather than discarded, when
using paths that include error-prone links. Such applications can
tolerate payload corruption and may choose to use the Lightweight User
Datagram Protocol (UDP-Lite) The service may be multicast and/or
unicast</t>
<t>[EDITOR'S NOTE: compare to UDP]</t>
<t>[RFC3828] and [RFC 5405/bis]</t>
</section>
<section title="Datagram Congestion Control Protocl (DCCP)">
<t>The Datagram Congestion Control Protocol (DCCP) [RFC4340] is a
bidirectional transport protocol that provides unicast connections of
congestion-controlled unreliable messages. DCCP is suitable for
applications that transfer fairly large amounts of data and that can
benefit from control over the tradeoff between timeliness and
reliability.</t>
<t>[EDITOR'S NOTE: Describe the aspects(?) of DCCP...]</t>
<t>[FC4340 et al]</t>
</section>
<section title="Realtime Transport Protocol (RTP)">
<t>RTP provides an end-to-end network transport service, suitable for
applications transmitting real-time data, such as audio, video or
data, over multicast or unicast network services, including TCP, UDP,
UDP-Lite, DCCP.</t>
<t>[EDITOR'S NOTE: Describe the aspects(?) of RTP...]</t>
</section>
<section title="Hypertext Transport Protocol (HTTP) as a pseudotransport">
<t>HTTP provides end-to-end network unicast transport service.</t>
<t>[EDITOR'S NOTE: Reference BCP 56, note that this implies TCP but
also brings with it object semantics you may not want.]</t>
<section title="WebSockets">
<t>[EDITOR'S NOTE: point out how websockets kind of fixes this.]</t>
</section>
</section>
</section>
<section anchor="Services" title="Transport service components">
<t>Aspects as derived from the subsections above.</t>
<t>This section is blank for now.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors were part-funded by the European Community under its
Seventh Framework Programme. The views expressed are solely those of the
authors.</t>
<t>Comments are welcome to the authors or via the IETF TAPS mailing
lists.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>XXX RFC ED - PLEASE REMOVE THIS SECTION XXX</t>
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document introduces no new security considerations. Each RFC
listed in this document discusses the security considerations of the
specification it contains.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<?rfc
?>
<?rfc include="reference.RFC.2460"
?>
<?rfc include="reference.RFC.0791" ?>
<?rfc ?>
<?rfc
?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.0768" ?>
<?rfc include="reference.RFC.0793" ?>
<?rfc include="reference.RFC.0896" ?>
<?rfc include="reference.RFC.5405"
?>
<?rfc include="reference.RFC.4340" ?>
<?rfc include="reference.RFC.4960" ?>
<?rfc include="reference.RFC.5348"
?>
<!-- CoDel -->
<!-- DRR -->
</references>
<!--RFC768;
&RFC793;
&RFC4960;
&RFC5405;
&RFC4614;
&RFC4340;
-->
<!--
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:05:26 |