One document matched: draft-thomson-rtcweb-data-00.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" ipr="trust200902">
  <front>
    <title abbrev="Web Data Channels">
      Data Channels for RTCWEB
    </title>

    <author initials="M" surname="Thomson" fullname="Martin Thomson">
      <organization>Microsoft</organization>
      <address>
        <postal>
          <street>3210 Porter Drive</street>
          <city>Palo Alto</city>
          <region>CA</region>
          <code>94304</code>
          <country>US</country>
        </postal>
        <phone>+1 650-353-1925</phone>
        <email>martin.thomson@skype.net</email>
      </address>
    </author>

    <date month="February" year="2013"/>
    <area>RAI</area>
    <workgroup>RTCWEB</workgroup>
    <keyword>API</keyword>
    <keyword>Web</keyword>
    <keyword>Real-Time</keyword>
    <keyword>Realtime</keyword>
    <keyword>SCTP</keyword>
    <keyword>Data</keyword>
    <keyword>Channel</keyword>
    <keyword>API</keyword>

    <abstract>
      <t>
        RTCWEB have selected SCTP over DTLS over UDP with ICE for peer-to-peer data channels.  There is some debate over the best way to negotiate channels.  This proposal is a nose-to-tail description of an alternative to existing proposals.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>
        <xref target="I-D.ietf-rtcweb-overview">RTCWEB</xref> has defined the use of the <xref target="RFC4960">Stream Control Transmission Protocol (SCTP)</xref> over <xref target="RFC6347">Datagram Transport Layer Security (DTLS)</xref> over UDP with <xref target="RFC5245">Interactive Connectivity Establishment (ICE)</xref> for peer-to-peer data channels.
      </t>
      
      <t>
        This document describes a proposal for how this protocol stack is used.  The proposal attempts to reconcile the following basic requirements:
        <list style="symbols">
          <t>the ability to have data channels used interchangeably with websockets, after establishment</t>
          <t>the ability to use as many SCTP features as possible</t>
        </list>
      </t>
      
      <t>
        Like other proposals, this proposal uses an API that is largely interchangeable with the WebSockets API [REF:TBD].  Of course, that alone is insufficient because the way that data channels are created is completely different to <xref target="RFC6455">websockets</xref>.  Only the general usage of the API follows the WebSockets API, channel establishment requires a very different process.
      </t>

      <t>
        Furthermore, not every application will care for compatibility with the WebSockets API.  For those applications, additional properties are exposed to enable valuable SCTP features.
      </t>

      <t>
        In these aspects, all data channel proposals are the same.  The details differ.  For example, this one doesn't need an in-band protocol.  It even avoids the need for negotiation, except where it is needed.  If not for the fact that the WebSockets API designers - in their infinite wisdom - decided to distinguish text from binary, it wouldn't even need to use a PPID to identify textual messages.
      </t>

      <section title="Terminology">
	<t>In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, <xref target="RFC2119">RFC 2119</xref> and indicate requirement levels for compliant implementations.
	</t>
      </section>
    </section>

    <section title="Overview of Operation">
      <t>
        A data channel is a bidirectional communication medium between WebRTC peers.
      </t>

      <t>
        Every data channel is bound to a specific SCTP stream number.  The same SCTP stream identifier is used for both directions of the data channel.  Though SCTP streams are unidirectional, and this concept doesn't hold any particular meaning for SCTP, this simplification ensures that channels can be created with minimal overhead.
      </t>

      <t>
        Each data channel has a set of properties that governs how it sends messages.  Unlike other SCTP APIs where properties like reliability settings are set on a per-message basis, this API places these properties on the data channel.  This allows the API to behave exactly like the WebSockets API when sending messages.  Details of the available data channel properties are included in <xref target="properties"/>.
      </t>

      <t>
        There are three ways that a data channel can be created.  All three result in an object representing the data channel being provided to the application.  Each differs in the manner of delivery and how properties are selected for the data channel.
        <list style="numbers">
          <t>
            The application can request the creation of a new data channel directly.  The browser selects appropriate properties for the channel, using any values provided by the application and providing defaults for others.
            <vspace blankLines="1"/>
            This triggers a notification to the application that indicates that it needs to renegotiate the session.
          </t>
          <t>
            Offer/answer negotiation can trigger the creation of a new data channel.  In this case, the session description provided in an offer or answer describes the properties of the channel.
          </t> 
          <t>
            Messages can arrive on an SCTP stream that does not have a data channel allocated.  If messages arrive on a stream, the browser provides default values for all stream properties.
          </t>
        </list>
      </t>
      <t>
        Channel creation can fail if there are an insufficient number of available SCTP streams.  This is based on either a local unwillingness to receive more streams, or based on knowledge of the unwillingness of the peer to receive more streams.  
      </t>

      <t>
        Creation can also fail if the application specifies a stream ID that is already in use.  These should trigger the appropriate error mechanisms (exceptions or something).
      </t>

      <t>
        Channels are closed by sending a RE-CONFIG chunk that includes Incoming and Outgoing SSN Reset Request parameters, as defined in <xref target="RFC6525"/>.  Closing a channel doesn't permit the sending of a code and message as exposed in the WebSockets API, any values that are provided by the application are discarded.
      </t>
    </section>

    <section title="(In)consistent Properties">
      <t>The creation of the first data channel will require offer/answer negotiation.  This is necessary to ensure that the SCTP association is created, including ICE, the DTLS handshake, plus any authentication that might be required.
      </t>

      <t>
        Once an SCTP association is live, data channels can be used to exchange messages immediately after they are created.  The drawback is that messages arrive at the peer without any information about what properties the sender attaches to the corresponding data channel.
      </t>

      <t>
        How much property consistency matters to the application will depend on the application.  If the application is performing SS7 signaling using <xref target="RFC4666">M3UA</xref>, this is unlikely to matter, but some applications could rely on having consistent data channel properties.
      </t>

      <section title="Negotiation">
        <t>
          The safest (and slowest) way to establish new channels with consistent properties is to negotiate them.  This is performed using an offer/answer exchange.  The application is able to choose where and when this negotiation occurs.  If there is an existing data channel, then this provides a low latency path for performing this negotiation.
        </t>

        <t>
          The negotiation includes a description for every SCTP stream that a peer is sending that includes all of the data channel properties (see <xref target="properties"/>), so that the receiver can create a data channel with the same properties.  The browser creates a data channel with the described properties and provides that to the application.  If the data channel description appears in an offer, the answer describes the data channel that is used on the same stream number.
        </t>

        <t>
          An offer or answer that includes a description for a data channel that already exists, then the properties of that data channel are not modified.  An answer MUST include the properties of the existent data channel, not the channel that the offer describes.
        </t>
      </section>

      <section title="Dealing with Mismatched Properties">

        <t>An application that chooses to send on data channels prior to negotiation will cause the receiving peer to create a data channel with a default configuration.  Applications can handle this in a number of ways:
        <list style="symbols">
          <t>
            The application on the receiving peer can create data channels in the same order as the sender to ensure consistent properties.  This is possible because stream identifiers are assigned in the same way by both peers.
          </t>
          <t>
            The application on the receiving peer might apply application-specific default values for all non-negotiated channels.
          </t>
          <t>
            The application on the receiving peer might not care about having consistent data channel properties.  Note that data channel properties only apply to the sending of messages.
          </t>
        </list>
        </t>
        <t>
          Note: It is possible to provide an application with information about the values that are in use by a peer.  This would in most cases be possible after negotiation, though some properties are revealed when new messages arrive.  Of course, this is a lot of effort after the application has already effectively declared that it doesn't care.  Given that the application could exchange this information using the data channel(s) it has convenient, adding new APIs seem of very low value.
        </t>

        <t>
          [[Irrelevant API Note:  Adding a data channel triggers a notification to the application that it should renegotiate the session.  Normally, the 'negotiation needed' state is cleared when the negotiation commences (or completes?).  If the application decides to send packets, then the damage is done and there is no point negotiating.  That being the case, a data channel could removed from the set of unnegotiated things upon sending a packet.  Negotiation from this point isn't going to change anything.]]
        </t>
      </section>
    </section>

    <section anchor="properties" title="Available Data Channel Properties">
      <t>
        The following properties are exposed to the application.  All of these properties can be set during the creation of a data channel.  Once the channel object is created, these properties are mutable, with the exception of <spanx style="verb">streamId</spanx>.

        <list style="hanging">
          <t hangText="streamId">
            The SCTP stream ID to use for the channel.  If not provided by the application, the lowest valued stream ID that is not already in use by a data channel is selected.  If the channel is created as a result of negotiation or packet arrival, the stream ID has already been chosen.
          </t>

          <t hangText="binaryPPID">
            The SCTP payload protocol identifier (PPID) that is used for binary messages.  Textual messages are always sent using a PPID that indicates textual content, so this value only determines the PPID that is attached to binary messages.  This field is a 32-bit number.
            <vspace blankLines="1"/>
            Unless otherwise specified, channels use the PPID for WebRTC binary data channels.  Channels created in response to the receipt of a message use the PPID from the received message, unless the message uses the PPID for WebRTC textual data channels, which causes the binary PPID to be selected instead.  Details on the newly defined PPIDs are included in <xref target="ppid"/>.
          </t>

          <t hangText="reliabilityTime">
            The amount of time (in milliseconds) that the browser will attempt to retransmit messages for reliable delivery.  Together with reliabilityRetransmissions, this enables unreliable or partially reliable transmission of data.  The default value for this property is the largest number available (e.g., Number.POSITIVE_INFINITY).
          </t>

          <t hangText="reliabilityRetransmissions">
            The numer of retransmissions that the browser will make for any packet reliable delivery.  Together with reliabilityTime, this enables unreliable or partially reliable transmission of data.  The default value for this property is the largest number available (e.g., Number.POSITIVE_INFINITY).
          </t>

          <t hangText="label">
            The label to assign to the data channel.  A default value is selected by the receiving browser.
          </t>

          <t hangText="protocol">
            A protocol label that identifies the protocol used on the data channel.  This property is undefined unless set by the application.
          </t>

          <t hangText="binaryType">
            The BinaryType defined in <eref target="http://dev.w3.org/html5/websockets/#binarytype">The WebSockets API</eref> determines whether binary data is provided to the application as Blob or ArrayBuffer objects.  The default value is <spanx style="verb">blob</spanx>.  Note that changing this might not have an immediate effect if messages have started to arrive prior to the change.
          </t>
        </list>
      </t>

      <t>
        All these properties are specific to each message that is sent.  Changes to mutable properties take effect for the next message that is sent on the channel.
      </t>

      <t>
        This isn't a W3C WebRTC document, so specifics of the API aren't really relevant, but it is imagined that these properties could be passed in a dictionary to the method that creates a new data channel and exposed as attributes on the data channel object.
      </t>
    </section>
      
    <section title="SDP Format">
      <t>
        The properties described above appear in SDP.  All properties are declarative.   Though the specifics of the syntax doesn't matter much, the following example could indicate something that would work:
      </t>

      <figure>
        <artwork><![CDATA[
m=application 12345 SCTP/DTLS 0 1 2 5
c=IN IP6 ::1
a=fmtp:0 binaryPPID=177;label=control
a=fmtp:1 label=chat
a=fmtp:2 label=characters;reliabilityTime=2000;protocol=lrudfb
a=fmtp:5 label=bullets;reliabilityTime=5000
]]></artwork>
      </figure>

      <t>
        [[Formal SDP grammar TBD]]
      </t>

      <t>
        This assumes that the SCTP port number (inside the DTLS encapsulation) is fixed, so that this doesn't need to be indicated anywhere.  I'm not sure whether asking IANA for a port allocation makes sense though.
      </t>
    </section>

    <section anchor="ppid" title="Payload Protocol Identifiers">
      <t>
        Two SCTP payload protocol identifiers are defined for WebRTC data channels.
      </t>
      <t>
        The WebRTC textual data channel PPID (number TBD) is used for all messages that are identified as being textual.  The payload of messages marked with this PPID MUST be UTF-8 encoded text.
      </t>
      <t>
        The WebRTC binary data channel PPID (number TBD) is used as the default PPID for new data channels.
      </t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>
        This document probably should register the PPIDs, but I don't really have time to do that right now.
      </t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>
        I thought about this, and I can't think of any specific security considerations.  I could blather on about willingness to accept streams and large volumes of data, but that's pretty lame.
      </t>
      <t>
        I'm sure something will turn up eventually.
      </t>
    </section>
    
    <section title="Acknowledgments">
      <t>
        This document is a rush job.  If it survives for any longer than a couple of weeks, no doubt this section will come in handy.
      </t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.4566"?>
      <?rfc include="reference.RFC.4960"?>
      <?rfc include="reference.RFC.6525"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.I-D.ietf-rtcweb-overview"?>
      <?rfc include="reference.RFC.4666"?>
      <?rfc include="reference.RFC.5245"?>
      <?rfc include="reference.RFC.6347"?>
      <?rfc include="reference.RFC.6455"?>
    </references>
  </back>

</rfc>