One document matched: draft-jesup-rtcweb-data-01.xml
<?xml version="1.0"?>
<?rfc symrefs="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc ipr="trust200902"
docName="draft-jesup-rtcweb-data-01.txt" category='info'>
<front>
<title abbrev="data P2P in RTCWEB">
RTCWeb Datagram Connection
</title>
<author initials="R." surname="Jesup" fullname="Randell Jesup">
<organization>Mozilla</organization>
<address>
<postal>
<street></street>
<code></code>
<city></city>
<country></country>
</postal>
<email>randell-ietf@jesup.org</email>
</address>
</author>
<author initials="S." surname="Loreto" fullname="Salvatore Loreto">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>salvatore.loreto@ericsson.com</email>
</address>
</author>
<author initials="M." surname="Tuexen" fullname="Michael Tuexen">
<organization>Muenster University of Applied Sciences</organization>
<address>
<postal>
<street>Stegerwaldstrasse 39</street>
<code>48565</code>
<city> Steinfurt</city>
<country>Germany</country>
</postal>
<email>tuexen@fh-muenster.de</email>
</address>
</author>
<date year="2011" />
<area>RAI</area>
<workgroup>RTCWeb Working Group</workgroup>
<keyword></keyword>
<keyword></keyword>
<abstract>
<t>
This document investigates the possibilities for designing a generic transport
service that allows Web Browser to exchange generic data in a peer to peer way.
Several, already standardized by IETF, transport protocols and their properties are investigated in order
to identify the most appropriate one.
</t>
<t>
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The issue of how best to handle non-media data types in the context of RTCWEB is still under discussion
in the mailing list; there have been several proposals on how to address this problem, but there is not yet a clear consensus
on the actual solution.</t>
<t>However it seems to be a general agreement that for NAT traversal purpose it has to be:</t>
<t>FOO/UDP/IP</t>
<t>or most likely:</t>
<t>FOO/DTLS/UDP/IP (for confidentiality, source authenticated, integrity protected transfers)</t>
<t>where FOO is a protocol that is supposed to provide congestion control and possible some type of framing or stream concept.</t>
<t>Moreover there has been a clear interest for both an unreliable and a reliable peer to peer datagram based channel.</t>
<t>This document provides Requirement and use cases for both unreliable and reliable peer to peer datagram base channel,
provide an overview of the pro and cons of the different proposed solutions, and finally analyze in more detail the SCTP
based solution.</t>
</section>
<section title="Requirements">
<t>
This section lists the requirements for P2P data connections between two browsers.
</t>
<t><list style="hanging">
<t hangText="Req. 1">Multiple simultaneous datagram streams must be supported. Note that there may 0 or more media streams in parallel with the data streams, and the number and state (active/inactive) of the media streams may change at any time.</t><t></t>
<t hangText="Req. 2">Both reliable and unreliable datagram streams must be supported.</t><t></t>
<t hangText="Req. 3">Data streams must be congestion controlled; either individually,
as a class, or in conjunction with the media streams, to ensure
that datagram exchanges don't cause congestion problems for the
media streams, and that the rtcweb PeerConnection as a whole is
fair with competing streams such as TCP.</t><t></t>
<t hangText="Req. 4">The application should be able to provide guidance as to the
relative priority of each datagram stream relative to each other,
and relative to the media streams. [ TBD: how this is encoded and
what the impact of this is. ] This will interact with the
congestion control.</t><t></t>
<t hangText="Req. 5">Datagram streams must be encrypted; allowing for confidentiality,
integrity and source authentication. See the security spec [xxx] for detailed info.</t><t></t>
<t hangText="Req. 6">Consent and NAT traversal mechanism: These are handled by the
PeerConnection's ICE <xref target="RFC5245"/> connectivity checks and
optional TURN servers.</t><t></t>
<t hangText="Req. 7"> Data streams MUST provide message fragmentation support such that IP-layer fragmentation does not occur no matter how large a message/buffer the Javascript application passes down to the Browser to be sent out.</t><t></t>
<t hangText="Rec. 8"> The data stream transport protocol MUST NOT encode local IP addresses inside its protocol fields; doing so reveals potentially private information, and leads to failure if the address is depended upon. </t><t></t>
<t hangText="Req. 9"> The data stream protocol SHOULD support unbounded-length "messages" (i.e., a virtual socket stream) at the application layer, for such things as image-file-transfer; or else it MUST support at least a maximum application-layer message size of 4GB.</t><t></t>
<t hangText="Req. 10"> The data stream packet format/encoding MUST be such that it is impossible for a malicious Javascript to generate an application message crafted such that it could be interpreted as a native protocol over UDP - such as UPnP, RTP, SNMP, STUN, etc. </t><t></t>
<t hangText="Req. 10"> The data stream transport protocol MUST start with the assumption
of a PMTU of 1280 [ *** need justification ***] bytes until measured otherwise. </t><t></t>
<t hangText="Req. 11"> The data stream transport protocol MUST NOT rely on ICMP being generated
or being passed back, such as for PMTU discovery. </t><t></t>
</list></t>
</section>
<section title="Use cases." anchor="sec-use-cases">
<section title="Use cases for unreliable datagram based channel" anchor="sec-use-cases-unreliable">
<t><list style="hanging">
<t hangText="U-C 1">A real-time game where position and object state information is
sent via one or more unreliable data channels. Note that at any time there may be no media channels, or all media channels may be inactive.</t><t></t>
<t hangText="U-C 2">Non-critical state updates about a user in a video chat or
conference, such as Mute state.</t><t></t>
</list></t>
</section>
<section title="Use cases for reliable channels (datagram or stream)." anchor="sec-use-cases-reliable">
<t>Note that either reliable datagrams or streams are possible; reliable streams would be fairly simple to layer on top of SCTP reliable datagrams with in-order delivery.</t><t></t>
<t><list style="hanging">
<t hangText="U-C 3"> A real-time game where critical state information needs to be
transferred, such as control information. Typically this would be datagrams. Such a game may
have no media channels, or they may be inactive at any given time, or may only be added
due to in-game actions.</t><t></t>
<t hangText="U-C 4">Non-realtime file transfers between people chatting. This could be datagrams or streaming; streaming might be an easier fit</t><t></t>
<t hangText="U-C 5">Realtime text chat while talking with an individual or with multiple people in a
conference. Typically this would be datagrams.</t><t></t>
<t hangText="U-C 6">Renegotiation of the set of media streams in the PeerConnection. Typically this would be datagrams</t><t></t>
</list></t>
</section>
</section>
<section title="Protocol alternatives" anchor="sec-p-a">
<section title="Datagrams over DTLS over DCCP over UDP." anchor="sec-p-a-1">
<figure title="stack diagram" anchor="fig-1"><artwork>
<![CDATA[
+------+
|WEBAPP|
+------+
| DTLS |
+-------------+
| STUN | DCCP |
+-------------+
| ICE |
+-------------+
| UDP1 | UDP2 |...
+-------------+
]]>
</artwork></figure>
<t>DCCP <xref target="RFC4340"/> adds to a UDP-like foundation the minimum mechanisms necessary to support congestion control.
It is a unicast, connection-oriented protocol with bidirectional data flow.</t>
<t>The main downside of DCCP is the uncertainty of the DCCP implementations. Moreover DCCP only
meets the requirements for the unreliable data channel, so in order to satisfy the reliable data channel requirements
there is a need to build a new mechanism on top of DCCP or use a different protocol for it.</t>
<t>The main advantage of DCCP is that the Congestion Control (CC) methods are modularly separated from its core, that allows each application to choose
a different congestion control methods it prefers. Each congestion control method is denoted by unique ID (CCID): a number from 0-255. CCIDs 2, 3 and
4 are current defined; CCIDs 0, 1, and 5-255 are reserved. The end-points negotiate their CCIDs during connection initiation and achieve agreement
through the exchange of feature negotiation options in DCCP headers.</t>
<t>CCID 2 <xref target="RFC4341"/> denotes Additive Increase, Multiplicative Decrease congestion control with feature modelled directly on TCP. It achieves the maximum bandwidth
over the long term consistent with the use of end-to-end congestion control but reduces the congestion window by half upon congestion detection.
Applications that prefer a large amount of bandwidth as feasible over the longer terms should use CCID2. </t>
<t>CCID 3 <xref target="RFC4342"/>, TCP friendly rate control mechanism(TFRC), denotes an equation-based and rate controlled congestion control mechanisms designed
to be reasonably fair when competing for bandwidth with TCP like flows. It shows much lower variation of throughput over time compared with TCP that makes CCID 3
more suitable than CCID 2 for applications such as streaming media content that prefers to minimize abrupt changes in the sending rate. </t>
<t>CCID 4 <xref target="RFC5622"/> is a modified version of CCID 3 and designed for applications that use a small fixed segment size, or change their sending rate by varying the segment size.
It denotes TFRC-SP (TCP friendly rate control for small packets)</t>
<t> Both CCID 3 and 4 uses the TCP throughput equation for CC; the former is based on the calculation of loss event rate but the later also include nominal packet
size of 1460 bytes, a round trip estimate in TCP throughput calculation. In contrast to CCID 3, the CCID 4 sender imposes a minimum interval of 10 ms
between data packets regardless of the allowed transmit rate.</t>
</section>
<section title="Datagrams over SCTP over DTLS over UDP." anchor="sec-p-a-2">
<figure title="stack diagram" anchor="fig-2"><artwork>
<![CDATA[
+------+
|WEBAPP|
+------+
| SCTP |
+-------------+
| STUN | DTLS |
+-------------+
| ICE |
+-------------+
| UDP1 | UDP2 |...
+-------------+
]]>
</artwork></figure>
<t>An SCTP <xref target="RFC4960"/> based solution will provide several interesting features among the others: Multistreaming, Ordered and Unordered delivery,
Reliability and partial-Reliability <xref target="RFC3758"/>, and Dynamic Address Reconfiguration <xref target="RFC5061"/>.</t>
<t>Moreover SCTP provides the possibility to transport different "protocols" over multiple streams and associations using the ppid (Payload Protocol Identifier).
An application can set a different PPID with each send call. This allows the receiving application to look at this information (as well as the stream id/seq) on receiving
to know what type of protocol the data payload has.</t>
<t>The SCTP feature so seems to satisfy all the requirements for both the unreliable and the reliable scenario.</t>
<t>There are SCTP implementations for all the different OS: Linux (mainline kernel 2.6.36), FreeBSD (release kernel 8.2), Mac OS X, Windows (SctpDrv4) and Solaris (OpenSolaris 2009.06),
as well as a user-land SCTP implementation based on the FreeBSD implementation).</t>
<t>The SCTP solution is analyzed in more detail in <xref target='sec-sctp'/>.</t>
</section>
<section title="A new protocol on top of UDP." anchor="sec-p-a-3">
<t>This option requires to at least build a congestion control (CC) mechanism on top
of the plain UDP.</t>
<t>In designing it we have to follow carefully the guidelines provided in <xref target="RFC5405"/>.</t>
<figure title="stack diagram UDP" anchor="fig-3"><artwork>
<![CDATA[
+------+
|WEBAPP|
+------+
| CC |
+-------------+
| STUN | DTLS |
+-------------+
| ICE |
+-------------+
| UDP1 | UDP2 |...
+-------------+
]]>
</artwork></figure>
<section title="TCP over DTLS over UDP." anchor="sec-p-a-3-1">
<figure title="stack diagram" anchor="fig-TCP_over_UDP"><artwork>
<![CDATA[
+------+
|WEBAPP|
+------+
|FRAME |
+------+
| TCP |
+-------------+
| STUN | DTLS |
+-------------+
| ICE |
+-------------+
| UDP1 | UDP2 |...
+-------------+
]]>
</artwork></figure>
<t>Layering TCP atop DTLS or UDP is an approach that has been suggested several times in the past, including TCP-over-UDP
<xref target='I-D.baset-tsvwg-tcp-over-udp'/> and UDP-Encapsulated Transport Protocols <xref target='I-D.denis-udp-transport'/>.</t>
<t>A similar mechanism has also been used for Google Talk's peer-to-peer file transfer protocol, implemented in the libjingle library as "PseudoTcp"
[http://code.google.com/p/libjingle/source/browse/trunk/talk/p2p/base/pseudotcp.cc].
In this implementation, a lightweight userspace TCP stack has been developed with support for a fairly minimal set of TCP options, namely delayed acknowledgements,
Nagle, fast retransmit, fast recovery (NewReno), timestamps, and window scaling. Some features have been removed, such as urgent data.
And as in the aforementioned drafts, the TCP header has been tweaked slightly to remove fields redundant with the UDP header, namely source/destination port and checksum.</t>
<t>The advantage of this approach is clear; TCP is well-known and understood, and its congestion control is by definition TCP-fair. User-space implementations of TCP exist, e.g. as PseudoTcp, which has considerable deployment experience. It is also possible to support multiplexing of datagram flows with this approach, either by adding a stream identifier to the TCP header (in place of the port numbers, perhaps), or doing the same in a higher-level framing layer.</t>
<t>This approach has some disadvantages as well; since TCP is a stream, rather than datagram-oriented protocol, some framing needs to be added on top of TCP to provide the necessary datagram interface to the calling API. In addition, TCP only provides reliable delivery; there is no provision for a unreliable channel. This deficiency could be remedied by providing a separate protocol for unreliable channels.</t>
<t>Such a protocol could be a lightweight datagram protocol that implements the sequence number and other fields necessary to run TFRC-SP.</t>
</section>
</section>
<section title="A RTP compatible protocol." anchor="sec-p-a-4">
<figure title="stack diagram" anchor="fig-RTP_comp"><artwork>
<![CDATA[
+------+
|WEBAPP|
+----------------+
|STUN|DTLS| SRTP |
+----------------+
| ICE |
+----------------+
| UDP1 | UDP2 |...
+----------------+
]]>
</artwork></figure>
<t>When sending RTP with DTLS, rather than encapsulating RTP in DTLS, SRTP keys are extracted from the DTLS key material, allowing use of SRTP's more efficient format. This same approach could be extended for sending of application data as a RTP payload.</t>
<t>The benefits of this approach are centered around the ability to reuse the existing mechanisms for audio/video data for application data, and the resultant simplification that occurs. If everything ends up RTP, and RTP provides information about loss and timing, we can have common encryption, congestion control, and multiplexing mechanisms for all types of data. For example, we could use RTP SSRC to demux different application data streams, and RTCP NACK to faciliate reliable delivery.</t>
<t>On the other hand, RTP has a number of semantics associated with it that aren't necessarily a good fit for arbitrary application data. While the RTP timestamp, sequence number and SSRC fields are meaningful, there are a number of other header fields that may not make sense, and the applicability of RTP's notions of timing, media playout, and control feedback is unclear.</t>
</section>
</section>
<section title="Datagrams over SCTP over DTLS over UDP." anchor="sec-sctp">
<section title="User Space vs Kernel implementation." anchor="sec-sctp-1">
<t>Even kernel implementation of SCTP are already available for all the different platforms (see <xref target='sec-p-a-2'/> ),
there are compelling reasons that incline towards for a SCTP stack that works well in user land.</t>
<t>The main reason is deployability.</t>
<t>There are many applications today that are expected to run on a wide range of old and new operating systems.
Web browsers are an excellent example. They support operating systems 10 years old or more, they run on mobile and desktop operating systems,
and they are highly portable to new operating systems. This is achieved by having a fairly narrow portability layer to minimize what needs
to be supported on old operating systems and ported to new ones. This creates a strong desire to implemented as much functionality as possible
inside the application instead of relying on the operating system for it.</t>
<t>This leads to a situation where there is a desire for the SCTP stack to be implemented in the user space instead of the kernel space.
For many applications that require support of operating systems without SCTP (insert whatever stack order is - UDP, DTLS - whatever),
there is no way to deploy this unless it can be implemented in the application.
The traditional reasons for kernel implementations, such as mux of many application using transport port numbers, does not particularly apply here
where that level of multiplexing between application was provided by the underling UDP that is tunneled over. The requirement is:</t>
<t>It MUST be possible to implement the SCTP and DTLS portion of the stack in the user application space.</t>
</section>
<section title="The envisioned usage of SCTP in the RTCWeb context" anchor="sec-sctp-2">
<t>The appealing features of SCTP in the RTCWeb context are:</t>
<t><list style="hanging">
<t hangText="-">the congestion control which is TCP friendly.</t>
<t hangText="-">the congestion control is modifiable for integration with media stream congestion control.</t>
<t hangText="-">support for multiple channels with different characteristics.</t>
<t hangText="-">support for out-of-order delivery.</t>
<t hangText="-">support for large datagrams and PMTU-discovery and fragmentation.</t>
<t hangText="-">the reliable or partial reliability support.</t>
</list></t>
<t>Multi streaming is probably also of interest.</t>
<t>Multihoming will not be used in this scenario. The SCTP layer would simply act as if it were running on a single-homed host,
since that is the abstraction that the lower layers (e.g. UDP) would expose.</t>
</section>
<section title="SCTP/DTLS/UDP vs DTLS/SCTP/UDP" anchor="sec-sctp-3">
<t>The two alternatives being discussed in this subsection are shown
in the following <xref target='fig-sctp-layering'/>.</t>
<figure title='Two variants of SCTP and DTLS usage' anchor='fig-sctp-layering'>
<artwork>
+------+ +------+
|WEBAPP| |WEBAPP|
+------+ +------+
| DTLS | | SCTP |
+-------------+ +-------------+
| SRTP | SCTP | | SRTP | DTLS |
+-------------+ +-------------+
| ICE | | ICE |
+-------------+ +-------------+
| UDP1 | UDP2 |... | UDP1 | UDP2 |...
+-------------+ +-------------+
</artwork>
</figure>
<t>The UDP encapsulation of SCTP used in the protocol stack
shown on the left hand side of <xref target='fig-sctp-layering'/>
is specified in <xref target='I-D.ietf-tsvwg-sctp-udp-encaps'/> and the
usage of DTLS over SCTP is specified in <xref target='RFC6083'/>.
Using the UDP encapsulation of SCTP allows SCTP implementations
to run in user-land without any special privileges, but still allows
the support of SCTP kernel implementations.
This also requires no SCTP specific support in middleboxes like firewalls and
NATs. Multihoming and failover support is implemented via the ICE layer,
and SCTP associations are single-homed at the SRTP layer.
The SCTP payload is protected by DTLS, which
provides confidentiality, integrity and source authentication. SCTP-AUTH as
specified in <xref target='RFC4895'/> is used to provide integrity of
SCTP control information related to the user messages like the SCTP stream
identifier. Please note that the SCTP control information
(like the SCTP stream identifier) is sent unencrypted.</t>
<t>Considering the protocol stack on the right hand side of
<xref target='fig-sctp-layering'/>, the usage of DTLS over UDP is specified in
<xref target='I-D.ietf-tls-rfc4347-bis'/>. Using SCTP on top of DTLS is
currently unspecified. Since DTLS is typically implemented in user-land,
an SCTP user-land implementation has also to be used. Kernel SCTP implementations
can't be used. When using DTLS as the lower layer, only single homed SCTP
associations can be used, since DTLS does not expose any any address management
to its upper layer. DTLS implementations used for this stack must support
controlling fields of the IP layer like the DF-bit in case of IPv4 and the
DSCP field. This is required for performing path MTU discovery.
The DTLS implementation must also support sending user messages exceeding
the path MTU. When supporting multiple SCTP associations over a single DTLS
connection, incoming ICMP or ICMPv6 messages can't be processed by the SCTP
layer, since there is no way to identify the corresponding association.
Therefore the number of SCTP associations should be limited to one or ICMP and
ICMPv6 messages should be ignored.
In general, the lower layer interface of an SCTP implementation has to be
adopted to address the differences between IPv4 or IPv6 (being connection-less)
or DTLS (being connection-oriented).
When this stack is used, DTLS protects the complete SCTP packet, so it
provides confidentiality, integrity and source authentication
of the complete SCTP packet.</t>
<t>It should be noted that both stack alternatives support the usage of
multiple SCTP streams. A user message can be sent ordered or unordered
and, if the SCTP implementations support <xref target='RFC3758'/>,
with partial reliability. When using partial reliability, it might make
sense to use a policy limiting the number of retransmissions. Limiting
the number of retransmissions to zero provides a UDP like service where
each user messages is sent exactly once.</t>
<t>SCTP provides congestion control on a per-association base. This means
that all SCTP streams within a single SCTP association share the same
congestion window. Traffic not being sent over SCTP is not covered by
the SCTP congestion control.</t>
</section>
</section>
<section title="Message Format." anchor="sec-mes-format">
<t> TBD if we need also to design a framing or not.</t>
<t> At time of writing nobody has identified a real need for masking of UDP,
and DTLS is a much-preferred solution for encryption/authentication.</t>
<t>More SCTP already provides sequence number information (e.g. stream sequence numbers).
However there could be a need to support different kind of message (link in WebSocket where there is support
to distinguish between Unicode text and binary frames), since for SCTP they are all user message.
In the case there is this need a possibility is to map types to streams.</t>
</section>
<section title="Security Considerations" anchor="sec-security">
<t>
To be done.
</t>
</section>
<section title="IANA Considerations" anchor="sec-IANA">
<t>
This document does not require any actions by the IANA.
</t>
</section>
<section title="Acknowledgments">
<t>Many thanks for comments, ideas, and text from Cullen Jennings, Eric Rescorla,
Randall Stewart and Justin Uberti.</t>
</section>
</middle>
<back>
<references title="Informational References">
<?rfc include="reference.RFC.3758"?>
<?rfc include="reference.RFC.4340"?>
<?rfc include="reference.RFC.4341"?>
<?rfc include="reference.RFC.4342"?>
<?rfc include="reference.RFC.5622"?>
<?rfc include="reference.RFC.4895"?>
<?rfc include="reference.RFC.4960"?>
<?rfc include="reference.RFC.5061"?>
<?rfc include="reference.RFC.5245"?>
<?rfc include="reference.RFC.5389"?>
<?rfc include="reference.RFC.5405"?>
<?rfc include="reference.RFC.6083"?>
<?rfc include="reference.I-D.ietf-tls-rfc4347-bis"?>
<?rfc include="reference.I-D.ietf-tsvwg-sctp-udp-encaps"?>
<?rfc include="reference.I-D.baset-tsvwg-tcp-over-udp"?>
<?rfc include="reference.I-D.denis-udp-transport"?>
</references>
</back>
</rfc>
<!-- Change log
-->
| PAFTECH AB 2003-2026 | 2026-04-24 01:18:32 |