draft-ietf-rtcweb-data-channel-00.txt   draft-ietf-rtcweb-data-channel-01.txt 
RTCWeb Working Group R. Jesup RTCWeb Working Group R. Jesup
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Informational S. Loreto Intended status: Informational S. Loreto
Expires: September 7, 2012 Ericsson Expires: March 11, 2013 Ericsson
M. Tuexen M. Tuexen
Muenster Univ. of Appl. Sciences Muenster Univ. of Appl. Sciences
March 6, 2012 September 7, 2012
RTCWeb Datagram Connection RTCWeb Datagram Connection
draft-ietf-rtcweb-data-channel-00.txt draft-ietf-rtcweb-data-channel-01.txt
Abstract Abstract
The Web Real-Time Communication (WebRTC) working group is charged to The Web Real-Time Communication (WebRTC) working group is charged to
provide protocol support for direct interactive rich communication provide protocol support for direct interactive rich communication
using audio, video, and data between two peers' web-browsers. This using audio, video, and data between two peers' web-browsers. This
document describes the non-media data transport aspects of the WebRTC document describes the non-media data transport aspects of the WebRTC
framework. It provides an architectural overview of how the Stream framework. It provides an architectural overview of how the Stream
Control Transmission Protocol (SCTP) is used in the WebRTC context as Control Transmission Protocol (SCTP) is used in the WebRTC context as
a generic transport service allowing Web Browser to exchange generic a generic transport service allowing Web Browser to exchange generic
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 7, 2012. This Internet-Draft will expire on March 11, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 41 skipping to change at page 4, line 41
Req. 8 The data stream transport protocol must not encode local IP Req. 8 The data stream transport protocol must not encode local IP
addresses inside its protocol fields; doing so reveals addresses inside its protocol fields; doing so reveals
potentially private information, and leads to failure if the potentially private information, and leads to failure if the
address is depended upon. address is depended upon.
Req. 9 The data stream protocol should support unbounded-length Req. 9 The data stream protocol should support unbounded-length
"messages" (i.e., a virtual socket stream) at the "messages" (i.e., a virtual socket stream) at the
application layer, for such things as image-file-transfer; application layer, for such things as image-file-transfer;
or else it must support at least a maximum application-layer or else it must support at least a maximum application-layer
message size of 4GB. message size of 2GB.
Req. 10 The data stream packet format/encoding must be such that it Req. 10 The data stream packet format/encoding must be such that it
is impossible for a malicious Javascript to generate an is impossible for a malicious Javascript to generate an
application message crafted such that it could be application message crafted such that it could be
interpreted as a native protocol over UDP - such as UPnP, interpreted as a native protocol over UDP - such as UPnP,
RTP, SNMP, STUN, etc. RTP, SNMP, STUN, etc.
Req. 11 The data stream transport protocol must start with the Req. 11 The data stream transport protocol must start with the
assumption of a PMTU of 1280 [ *** need justification ***] assumption of a PMTU of 1280 [ *** need justification ***]
bytes until measured otherwise. bytes until measured otherwise.
skipping to change at page 6, line 39 skipping to change at page 6, line 39
each protocol a specific PPID and the receiver demultiplexes the each protocol a specific PPID and the receiver demultiplexes the
messages based on the received PPID. messages based on the received PPID.
The encapsulation of SCTP over DTLS, together with the SCTP features The encapsulation of SCTP over DTLS, together with the SCTP features
listed above satisfies all the requirements listed in in Section 2. listed above satisfies all the requirements listed in in Section 2.
The layering of protocols for WebRTC is shown in the following The layering of protocols for WebRTC is shown in the following
Figure 2. Figure 2.
+------+ +------+
|WEBAPP| |RTCWEB|
| DATA |
+------+ +------+
| SCTP | | SCTP |
+--------------------+ +--------------------+
| STUN | SRTP | DTLS | | STUN | SRTP | DTLS |
+--------------------+ +--------------------+
| ICE | | ICE |
+--------------------+ +--------------------+
| UDP1 | UDP2 | ... | | UDP1 | UDP2 | ... |
+--------------------+ +--------------------+
skipping to change at page 7, line 52 skipping to change at page 7, line 52
connection-less) or DTLS (being connection-oriented). connection-less) or DTLS (being connection-oriented).
When protocol stack of Figure 2 is used, DTLS protects the complete When protocol stack of Figure 2 is used, DTLS protects the complete
SCTP packet, so it provides confidentiality, integrity and source SCTP packet, so it provides confidentiality, integrity and source
authentication of the complete SCTP packet. authentication of the complete SCTP packet.
This protocol stack supports the usage of multiple SCTP streams. A This protocol stack supports the usage of multiple SCTP streams. A
user message can be sent ordered or unordered and, if the SCTP user message can be sent ordered or unordered and, if the SCTP
implementations support [RFC3758], with partial reliability. When implementations support [RFC3758], with partial reliability. When
using partial reliability, it might make sense to use a policy using partial reliability, it might make sense to use a policy
limiting the number of retransmissions. Limiting the number of limiting the number of retransmissions by time or number. Limiting
retransmissions to zero provides a UDP like service where each user the number of retransmissions to zero provides a UDP-like service
messages is sent exactly once. where each user message is sent exactly once.
SCTP provides congestion control on a per-association base. This SCTP provides congestion control on a per-association base. This
means that all SCTP streams within a single SCTP association share means that all SCTP streams within a single SCTP association share
the same congestion window. Traffic not being sent over SCTP is not the same congestion window. Traffic not being sent over SCTP is not
covered by the SCTP congestion control. Due to the typical parallel covered by the SCTP congestion control. Due to the typical parallel
SRTP media streams, it will be advantageous to select a delay- SRTP media streams, it will be advantageous to select a delay-
sensitive congestion control algorithm or to at least coordinate sensitive congestion control algorithm or to at least coordinate
congestion control between the data channels and the media streams to congestion control between the data channels and the media streams to
avoid a data channel transfer ending up with most or all the channel avoid a data channel transfer ending up with most or all the channel
bandwidth. bandwidth. Since SCTP does not have an internal negotiaton mechanism
for selecting a congestion control algorithm, the algorithm should be
negotiated before establishment of the SCTP associaton.
5. The Envisioned Usage of SCTP in the RTCWeb Context 5. The Envisioned Usage of SCTP in the RTCWeb Context
The appealing features of SCTP in the RTCWeb context are: The appealing features of SCTP in the RTCWeb context are:
o TCP-friendly congestion control. o TCP-friendly congestion control.
o The congestion control is modifiable for integration with media o The congestion control is modifiable for integration with media
stream congestion control. stream congestion control.
skipping to change at page 8, line 45 skipping to change at page 8, line 47
Multihoming will not be used in this scenario. The SCTP layer would 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 simply act as if it were running on a single-homed host, since that
is the abstraction that the lower layer (a connection oriented, is the abstraction that the lower layer (a connection oriented,
unreliable datagram service) would expose. unreliable datagram service) would expose.
5.1. Association Setup 5.1. Association Setup
The SCTP association would be set up when the two endpoints of the The SCTP association would be set up when the two endpoints of the
WebRTC PeerConnection agree on opening it, as negotiated by JSEP WebRTC PeerConnection agree on opening it, as negotiated by JSEP
(typically an exchange of SDP) [I-D.ietf-rtcweb-jsep]. It would use (typically an exchange of SDP) [I-D.ietf-rtcweb-jsep]. Additionally,
the DTLS connection created at the start of the PeerConnection the negotiation should include some type of congestion control
connection. selection. It would use the DTLS connection created at the start of
the PeerConnection connection.
The application should indicate the number of simultaneous streams The application should indicate the number of simultaneous streams
required when opening the association, and if no value is supplied, required when opening the association, and if no value is supplied,
the implementation should provide a default, with a suggested value the implementation should provide a default, with a suggested value
of 16. If more simultaneous streams are needed, [RFC6525] allows of 16. If more simultaneous streams are needed, [RFC6525] allows
adding additional (but not removing) streams to an existing adding additional (but not removing) streams to an existing
association. There can be up to 65536 SCTP streams per SCTP association. There can be up to 65535 SCTP streams per SCTP
association in each direction. association in each direction.
5.2. SCTP Streams 5.2. SCTP Streams
SCTP defines a stream as an unidirectional logical channel existing SCTP defines a stream as an unidirectional logical channel existing
within an SCTP association one to another SCTP endpoint. The streams within an SCTP association one to another SCTP endpoint. The streams
are used to provide the notion of in-sequence delivery. Each user are used to provide the notion of in-sequence delivery. Each user
message is sent on a particular stream, either order or unordered. message is sent on a particular stream, either order or unordered.
Ordering is preserved only for all ordered messages sent on the same Ordering is preserved only for all ordered messages sent on the same
stream. stream.
5.3. Channel Definition 5.3. Channel Definition
The W3C seems to have consensus on defining the application API for The W3C has consensus on defining the application API for WebRTC
WebRTC dataChannels to be bidirectional. They also consider the dataChannels to be bidirectional. They also consider the notions of
notions of in-sequence, out-of-sequence, reliable and un-reliable as in-sequence, out-of-sequence, reliable and un-reliable as properties
properties of Channels. of Channels. One strong wish is for the application-level API to be
close to the API for WebSockets, which implies bidirectional streams
of data and waiting for onopen to fire before sending, a textual
label used to identify the meaning of the stream, among other things.
A possible realization of a bidirectional Data Channel is a pair of A possible realization of a bidirectional Data Channel is a pair of
one incoming stream and one outcoming SCTP stream. one incoming stream and one outcoming SCTP stream.
Note that there's no requirement for the SCTP streams used to create
a bidirectional channel have the same number in each direction. How
stream values are selected and used to provide this functionality is
up to the protocol.
Closing of a Data Channel can be signalled resetting the Closing of a Data Channel can be signalled resetting the
corresponding streams [RFC6525]. Resetting a stream set the Stream corresponding streams [RFC6525]. Resetting a stream set the Stream
Sequence Numbers (SSNs) of the stream back to 'zero' with a Sequence Numbers (SSNs) of the stream back to 'zero' with a
corresponding notification to the application layer that the reset corresponding notification to the application layer that the reset
has been performed. Closed streams are available to reuse. has been performed. Closed streams are available to reuse.
[RFC6525] also guarantees that all the messages are delivered (or [RFC6525] also guarantees that all the messages are delivered (or
expired) before resetting the stream. expired) before resetting the stream.
It might be useful to use a specific pair of SCTP streams for
transporting control information.
5.4. Usage of Payload Protocol Identifier 5.4. Usage of Payload Protocol Identifier
The SCTP Payload Protocol Identifiers (PPIDs) can be used to signal The SCTP Payload Protocol Identifiers (PPIDs) can be used to signal
the interpretation of the "Payload data", like a string, ASCII or the interpretation of the "Payload data", like a string, ASCII or
binary data. binary data.
RFC 4960 [RFC4960] creates the registry from which these identifiers RFC 4960 [RFC4960] creates the registry from which these identifiers
have been assigned. Eventual PPIDs defined within the RTCWeb Context have been assigned. Eventual PPIDs defined within the RTCWeb Context
have to be registered with IANA. have to be registered with IANA.
6. Minor Protocol and Message Format 6. Minor Protocol and Message Format
A separate draft (draft-jesup-rtcweb-data-protocol) is being A separate draft (draft-jesup-rtcweb-data-protocol) proposes the
submitted to define the minor protocol to set up and manage the minor protocol to set up and manage the bidirectional data channels
bidirectional data channels needed to satisify the requirements in needed to satisify the requirements in this document for WebRTC.
this document for WebRTC.
Masking of the protocol is not needed if the lower layer always Masking of the protocol is not needed if the lower layer always
encrypts with DTLS. encrypts with DTLS.
7. Security Considerations 7. Security Considerations
To be done. To be done.
8. IANA Considerations 8. IANA Considerations
This document does not require any actions by the IANA. This document does not require any actions by the IANA.
9. Acknowledgments 9. Acknowledgments
Many thanks for comments, ideas, and text from Cullen Jennings, Eric Many thanks for comments, ideas, and text from Cullen Jennings, Eric
Rescorla, Randall Stewart, Justin Uberti, and Harald Alvestrand. Rescorla, Randall Stewart, Justin Uberti, Adam Bergkvist and Harald
Alvestrand.
10. Informative References 10. Informative References
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP) Conrad, "Stream Control Transmission Protocol (SCTP)
Partial Reliability Extension", RFC 3758, May 2004. Partial Reliability Extension", RFC 3758, May 2004.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
skipping to change at page 11, line 11 skipping to change at page 11, line 18
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control
Transmission Protocol (SCTP) Stream Reconfiguration", Transmission Protocol (SCTP) Stream Reconfiguration",
RFC 6525, February 2012. RFC 6525, February 2012.
[I-D.ietf-rtcweb-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for RTC-Web", Rescorla, E., "Security Considerations for RTC-Web",
draft-ietf-rtcweb-security-01 (work in progress), draft-ietf-rtcweb-security-03 (work in progress),
October 2011. June 2012.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "RTCWEB Security Architecture", Rescorla, E., "RTCWEB Security Architecture",
draft-ietf-rtcweb-security-arch-00 (work in progress), draft-ietf-rtcweb-security-arch-03 (work in progress),
January 2012. July 2012.
[I-D.ietf-rtcweb-jsep] [I-D.ietf-rtcweb-jsep]
Uberti, J. and C. Jennings, "Javascript Session Uberti, J. and C. Jennings, "Javascript Session
Establishment Protocol", draft-ietf-rtcweb-jsep-00 (work Establishment Protocol", draft-ietf-rtcweb-jsep-01 (work
in progress), March 2012. in progress), June 2012.
[I-D.ietf-tsvwg-sctp-udp-encaps] [I-D.ietf-tsvwg-sctp-udp-encaps]
Tuexen, M. and R. Stewart, "UDP Encapsulation of SCTP Tuexen, M. and R. Stewart, "UDP Encapsulation of SCTP
Packets", draft-ietf-tsvwg-sctp-udp-encaps-02 (work in Packets", draft-ietf-tsvwg-sctp-udp-encaps-04 (work in
progress), December 2011. progress), July 2012.
[I-D.tuexen-tsvwg-sctp-dtls-encaps] [I-D.tuexen-tsvwg-sctp-dtls-encaps]
Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS
Encapsulation of SCTP Packets for RTCWEB", Encapsulation of SCTP Packets for RTCWEB",
draft-tuexen-tsvwg-sctp-dtls-encaps-00 (work in progress), draft-tuexen-tsvwg-sctp-dtls-encaps-01 (work in progress),
March 2012. July 2012.
Authors' Addresses Authors' Addresses
Randell Jesup Randell Jesup
Mozilla Mozilla
USA USA
Email: randell-ietf@jesup.org Email: randell-ietf@jesup.org
Salvatore Loreto Salvatore Loreto
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: salvatore.loreto@ericsson.com Email: salvatore.loreto@ericsson.com
Michael Tuexen Michael Tuexen
Muenster University of Applied Sciences Muenster University of Applied Sciences
Stegerwaldstrasse 39 Stegerwaldstrasse 39
Steinfurt 48565 Steinfurt 48565
Germany Germany
Email: tuexen@fh-muenster.de Email: tuexen@fh-muenster.de
 End of changes. 22 change blocks. 
37 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/