RTCWeb Working Group R. Jesup
Internet-Draft Mozilla
Intended status: Informational S. Loreto
Expires: April 27, 2012 Ericsson
M. Tuexen
Muenster University of Applied
Sciences
October 25, 2011
RTCWeb Datagram Connection
draft-jesup-rtcweb-data-00.txt
Abstract
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. Different transport protocols and their
properties are investigated in order to identify the most appropriate
one.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 27, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Jesup, et al. Expires April 27, 2012 [Page 1]
Internet-Draft data P2P in RTCWEB October 2011
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use cases. . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Use cases for unreliable datagram based channel . . . . . 4
3.2. Use cases for reliable channels (datagram or stream). . . 4
4. Protocol alternatives . . . . . . . . . . . . . . . . . . . . 5
4.1. Datagrams over DTLS over DCCP over UDP. . . . . . . . . . 5
4.2. Datagrams over SCTP over DTLS over UDP. . . . . . . . . . 6
4.3. A new protocol on top of UDP. . . . . . . . . . . . . . . 6
4.4. A RTP compatible protocol. . . . . . . . . . . . . . . . . 7
5. Datagrams over SCTP over DTLS over UDP. . . . . . . . . . . . 7
5.1. User Space vs Kernel implementation. . . . . . . . . . . . 7
5.2. The envisioned usage of SCTP in the RTCWeb context . . . . 7
5.3. SCTP/DTLS/UDP vs DTLS/SCTP/UDP . . . . . . . . . . . . . . 8
6. Message Format. . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. Informational References . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Jesup, et al. Expires April 27, 2012 [Page 2]
Internet-Draft data P2P in RTCWEB October 2011
1. Introduction
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 proposal on how to address this problem, but there is
not yet a clear consensus on the actual solution.
However it seems to be a general agreement that for NAT traversal
purpose it has to be:
FOO/UDP/IP
or most likely:
FOO/DTLS/UDP/IP (for confidentiality, source authenticated, integrity
protected transfers)
where FOO is a protocol that is supposed to provide congestion
control and possible some type of framing or stream concept.
Moreover there has been a clear interest for both an unreliable and a
reliable peer to peer datagram based channel.
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.
2. Requirements
This section lists the requirements for P2P data connections between
two browsers.
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.
Req. 2 Both reliable and unreliable datagram streams must be
supported.
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.
Jesup, et al. Expires April 27, 2012 [Page 3]
Internet-Draft data P2P in RTCWEB October 2011
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.
Req. 5 Datagram streams must be encrypted; allowing for
confidentiality, integrity and source authentication. See the
security spec [xxx] for detailed info.
Req. 6 Consent and NAT traversal mechanism: These are handled by the
PeerConnection's ICE [RFC5245] connectivity checks and optional
TURN servers.
3. Use cases.
3.1. Use cases for unreliable datagram based channel
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.
U-C 2 Non-critical state updates about a user in a video chat or
conference, such as Mute state.
3.2. Use cases for reliable channels (datagram or stream).
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.
U-C 3 A real-time game where critical state information needs to be
transferred, such as control information. Typically this would be
datagrams.
U-C 4 Non-realtime file transfers between people chatting. This
could be datagrams or streaming; streaming might be an easier fit
U-C 5 Realtime text chat while talking with multiple people in a
conference. Typically this would be datagrams.
Jesup, et al. Expires April 27, 2012 [Page 4]
Internet-Draft data P2P in RTCWEB October 2011
U-C 6 Renegotiation of the set of media streams in the
PeerConnection. Typically this would be datagrams
4. Protocol alternatives
4.1. Datagrams over DTLS over DCCP over UDP.
+------+
|WEBAPP|
+------+
| DTLS |
+-------------+
| STUN | DCCP |
+-------------+
| UDP |
+-------------+
Figure 1: stack diagram
DCCP [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.
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.
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 method it prefers.
Jesup, et al. Expires April 27, 2012 [Page 5]
Internet-Draft data P2P in RTCWEB October 2011
4.2. Datagrams over SCTP over DTLS over UDP.
+------+
|WEBAPP|
+------+
| SCTP |
+-------------+
| STUN | DTLS |
+-------------+
| UDP |
+-------------+
Figure 2: stack diagram
An SCTP [RFC4960] based solution will provide several interesting
features among the others: Multistreaming, Ordered and Unordered
delivery, Reliability and partial-Reliability [RFC3758], and Dynamic
Address Reconfiguration [RFC5061]. The SCTP feature so seems to
satisfy all the requirements for both the unreliable and the reliable
scenario.
TBD: any downside for SCTP???
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).
The SCTP solution is analyzed in more detail in Section 5.
4.3. A new protocol on top of UDP.
This option requires to at least build a congestion control (CC)
mechanism on top of the plain UDP.
In designing it we have to follow carefully the guidelines provided
in [RFC5405].
Jesup, et al. Expires April 27, 2012 [Page 6]
Internet-Draft data P2P in RTCWEB October 2011
+------+
|WEBAPP|
+------+
| CC |
+-------------+
| STUN | DTLS |
+-------------+
| UDP |
+-------------+
Figure 3: stack diagram UDP
TBD: describe here the proposal to implement in the userspace TCP/
DTLS/UDP for reliable data channels, and UDP-with-TFRC/DTLS/UDP for
unreliable data channels (e.g. libjingle).
4.4. A RTP compatible protocol.
TBD
5. Datagrams over SCTP over DTLS over UDP.
5.1. User Space vs Kernel implementation.
Even kernel implementation of SCTP are already available for all the
different platforms (see Section 4.2 ), there are compelling reasons
that incline towards for a SCTP stack that works well in user land.
The main reason is deployability.
TBD..
5.2. The envisioned usage of SCTP in the RTCWeb context
The appealing features of SCTP in the RTCWeb context are:
- the congestion control which is TCP friendly.
- the congestion control is modifiable for integration with media
stream congestion control.
- support for multiple channels with different characteristics.
- support for out-of-order delivery.
- support for large datagrams and PMTU-discovery and fragmentation.
Jesup, et al. Expires April 27, 2012 [Page 7]
Internet-Draft data P2P in RTCWEB October 2011
- the reliable or partial reliability support.
Multi streaming is probably also of interest.
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.
5.3. SCTP/DTLS/UDP vs DTLS/SCTP/UDP
The two alternatives being discussed in this subsection are shown in
the following Figure 4.
+------+ +------+
|WEBAPP| |WEBAPP|
+------+ +------+
| DTLS | | SCTP |
+-------------+ +-------------+
| STUN | SCTP | | STUN | DTLS |
+-------------+ +-------------+
| UDP | | UDP |
+-------------+ +-------------+
Figure 4: Two variants of SCTP and DTLS usage
The UDP encapsulation of SCTP used in the protocol stack shown on the
left hand side of Figure 4 is specified in
[I-D.ietf-tsvwg-sctp-udp-encaps] and the usage of DTLS over SCTP is
specified in [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. However, if multihoming is
required, SCTP needs to setup the associations iteratively, which
requires support at the SCTP implementations. If WEBAPP does not use
multihoming, the support of the iterative association setup procedure
is not required. The SCTP payload is protected by DTLS, which
provides confidentiality, integrity and source authentication. SCTP-
AUTH as specified in [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.
Considering the protocol stack on the right hand side of Figure 4,
the usage of DTLS over UDP is specified in
[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
Jesup, et al. Expires April 27, 2012 [Page 8]
Internet-Draft data P2P in RTCWEB October 2011
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.
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 [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.
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.
6. Message Format.
TBD if we need also to design a framing or not.
At time of writing nobody has identified a real need for masking of
UDP, and DTLS is a much-preferred solution for encryption/
authentication.
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.
Jesup, et al. Expires April 27, 2012 [Page 9]
Internet-Draft data P2P in RTCWEB October 2011
7. Security Considerations
To be done.
8. IANA Considerations
This document does not require any actions by the IANA.
9. Acknowledgments
Many thanks for comments, ideas, and text from Cullen Jennings, Eric
Rescorla, Randall Stewart and Justin Uberti.
10. Informational References
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP)
Partial Reliability Extension", RFC 3758, May 2004.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
"Authenticated Chunks for the Stream Control Transmission
Protocol (SCTP)", RFC 4895, August 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
Kozuka, "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", RFC 5061,
September 2007.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405,
Jesup, et al. Expires April 27, 2012 [Page 10]
Internet-Draft data P2P in RTCWEB October 2011
November 2008.
[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
Transport Layer Security (DTLS) for Stream Control
Transmission Protocol (SCTP)", RFC 6083, January 2011.
[I-D.ietf-tls-rfc4347-bis]
Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security version 1.2", draft-ietf-tls-rfc4347-bis-06 (work
in progress), July 2011.
[I-D.ietf-tsvwg-sctp-udp-encaps]
Tuexen, M. and R. Stewart, "UDP Encapsulation of SCTP
Packets", draft-ietf-tsvwg-sctp-udp-encaps-00 (work in
progress), July 2011.
Authors' Addresses
Randell Jesup
Mozilla
Email: randell-ietf@jesup.org
Salvatore Loreto
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: salvatore.loreto@ericsson.com
Michael Tuexen
Muenster University of Applied Sciences
Stegerwaldstrasse 39
Steinfurt 48565
Germany
Email: tuexen@fh-muenster.de
Jesup, et al. Expires April 27, 2012 [Page 11]