draft-ietf-rtcweb-data-channel-03.txt   draft-ietf-rtcweb-data-channel-04.txt 
Network Working Group R. Jesup Network Working Group R. Jesup
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track S. Loreto Intended status: Standards Track S. Loreto
Expires: August 28, 2013 Ericsson Expires: August 29, 2013 Ericsson
M. Tuexen M. Tuexen
Muenster Univ. of Appl. Sciences Muenster Univ. of Appl. Sciences
February 24, 2013 February 25, 2013
RTCWeb Data Channels RTCWeb Data Channels
draft-ietf-rtcweb-data-channel-03.txt draft-ietf-rtcweb-data-channel-04.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 specifies the non-media data transport aspects of the WebRTC document specifies 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 August 28, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 5, line 29 skipping to change at page 5, line 29
with the congestion control algorithms. with the congestion control algorithms.
Req. 5 Data channels MUST be secured; allowing for confidentiality, Req. 5 Data channels MUST be secured; allowing for confidentiality,
integrity and source authentication. See integrity and source authentication. See
[I-D.ietf-rtcweb-security] and [I-D.ietf-rtcweb-security] and
[I-D.ietf-rtcweb-security-arch] for detailed info. [I-D.ietf-rtcweb-security-arch] for detailed info.
Req. 6 Data channels MUST provide message fragmentation support Req. 6 Data channels MUST provide message fragmentation support
such that IP-layer fragmentation can be avoided no matter such that IP-layer fragmentation can be avoided no matter
how large a message the Javascript application passes to be how large a message the Javascript application passes to be
sent. sent. It also MUST ensure that large data channel transfers
don't unduely delay traffic on other data channels.
Req. 7 The data channel transport protocol MUST NOT encode local IP Req. 7 The data channel 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. 8 The data channel transport protocol SHOULD support Req. 8 The data channel transport protocol SHOULD support
unbounded-length "messages" (i.e., a virtual socket stream) unbounded-length "messages" (i.e., a virtual socket stream)
at the application layer, for such things as image-file- at the application layer, for such things as image-file-
transfer; Implementations might enforce a reasonable message transfer; Implementations might enforce a reasonable message
size limit. size limit.
Req. 9 The data channel packet format/encoding MUST be such that it Req. 9 The data channel transport protocol SHOULD avoid IP
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.
Req. 10 The data channel transport protocol SHOULD avoid IP
fragmentation. It MUST support PMTU discovery and MUST NOT fragmentation. It MUST support PMTU discovery and MUST NOT
rely on ICMP or ICMPv6 being generated or being passed back, rely on ICMP or ICMPv6 being generated or being passed back,
especially for PMTU discovery. especially for PMTU discovery.
Req. 11 It MUST be possible to implement the protocol stack in the Req. 10 It MUST be possible to implement the protocol stack in the
user application space. user application space.
5. SCTP over DTLS over UDP Considerations 5. SCTP over DTLS over UDP Considerations
The important features of SCTP in the RTCWeb context are: The important 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 9, line 16 skipping to change at page 9, line 14
6. The Usage of SCTP in the RTCWeb Context 6. The Usage of SCTP in the RTCWeb Context
6.1. Association Setup 6.1. Association Setup
The SCTP association will be set up when the two endpoints of the The SCTP association will 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]. Additionally, (typically an exchange of SDP) [I-D.ietf-rtcweb-jsep]. Additionally,
the negotiation SHOULD include some type of congestion control the negotiation SHOULD include some type of congestion control
selection. It will use the DTLS connection selected via SDP; selection. It will use the DTLS connection selected via SDP;
typically this will be shared via BUNDLE with DTLS connections used typically this will be shared via BUNDLE or equivalent with DTLS
to key the DTLS-SRTP media streams. connections used to key the DTLS-SRTP media streams.
The application SHOULD indicate the initial number of streams The application SHOULD indicate the initial number of 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 an appropriate default. If more the implementation SHOULD provide an appropriate default. If more
simultaneous streams are needed, [RFC6525] allows adding additional simultaneous streams are needed, [RFC6525] allows adding additional
(but not removing) streams to an existing association. Note there (but not removing) streams to an existing association. Note there
can be up to 65536 SCTP streams per SCTP association in each can be up to 65536 SCTP streams per SCTP association in each
direction. direction.
6.2. SCTP Streams 6.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 and for are used to provide the notion of in-sequence delivery and for
multiplexing. Each user message is sent on a particular stream, multiplexing. Each user message is sent on a particular stream,
either order or unordered. Ordering is preserved only for all either order or unordered. Ordering is preserved only for ordered
ordered messages sent on the same stream. messages sent on the same stream.
6.3. Channel Definition 6.3. Channel Definition
The W3C has consensus on defining the application API for WebRTC The W3C has consensus on defining the application API for WebRTC
dataChannels to be bidirectional. They also consider the notions of dataChannels to be bidirectional. They also consider the notions of
in-sequence, out-of-sequence, reliable and un-reliable as properties in-sequence, out-of-sequence, reliable and un-reliable as properties
of Channels. One strong wish is for the application-level API to be of Channels. One strong wish is for the application-level API to be
close to the API for WebSockets, which implies bidirectional streams close to the API for WebSockets, which implies bidirectional streams
of data and waiting for onopen to fire before sending, a textual of data and waiting for onopen to fire before sending, a textual
label used to identify the meaning of the stream, among other things. label used to identify the meaning of the stream, among other things.
skipping to change at page 10, line 24 skipping to change at page 10, line 20
been performed. been performed.
[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.
6.4. Usage of Payload Protocol Identifier 6.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 the protocol specified the interpretation of the "Payload data", like the protocol specified
in [I-D.jesup-rtcweb-data-protocol] uses them to identify a in [I-D.jesup-rtcweb-data-protocol] uses them to identify a
Javascript string, a Javascript array or a Javascript blob. Javascript string, a Javascript binary data (ArrayBuffer or Blob) and
to provide fragmentation support for large messages that may cause
the message to monopolize the SCTP association.
7. Security Considerations 7. Security Considerations
This document does not add any additional considerations to the ones This document does not add any additional considerations to the ones
given in [I-D.ietf-rtcweb-security] and given in [I-D.ietf-rtcweb-security] and
[I-D.ietf-rtcweb-security-arch]. [I-D.ietf-rtcweb-security-arch].
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.
 End of changes. 10 change blocks. 
18 lines changed or deleted 15 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/