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

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-cbran-rtcweb-data-00"
     ipr="noDerivativesTrust200902">
  <front>
    <title abbrev="Abbreviated-Title">RTC-Web Non-Media Data Transport
    Requirements</title>

    <author fullname="Cary Bran" initials="C." surname="Bran">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <phone>+1 206 256-3502</phone>

        <email>cbran@cisco.com</email>
      </address>
    </author>

    <author fullname="Cullen Jennings" initials="C." surname="Jennings">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <phone>+1 408 421-9990</phone>

        <email>fluffy@cisco.com</email>
      </address>
    </author>

    <date day="4" month="July" year="2011" />

    <abstract>
      <t>This document outlines a protocol and requirements for RTC-Web client
      application to transmit real-time, non-media data.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This specification will focus on the transport of real-time non-media
      data requirements for RTC-Web client applications. An example of
      real-time non-media data, would be a characters screen position within
      an multiplayer HTML5 video game.</t>

      <t>The non-media data transport requirements fit into a series of
      specifications have been created to address RTC-Web negotiation and
      signaling protocols, security requirements, media transmission and use
      cases. More information on the RTC-Web can be found here:</t>

      <t>[TODO put links to supporting drafts here]</t>
    </section>

    <section title="Terminology">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </section>

    <section title="Non-Media Data Transport Requirements">
      <t>The RTC-WEB will enable for rich voice and video communications from
      client applications, such as a web browser. One of the natural
      extensions of the RTC-WEB and the work emerging from the HTML5 community
      is video games. Video games have a similar stringent real-time
      requirement for exchanging non-media data types such as a player’s
      screen position.</t>

      <t>The question of how best to handle non-media data types has been
      raised. There have been proposals to address this problem. Common to all
      proposals is how the data transport session is set up, using ICE <xref
      target="RFC5245"></xref> in a similar manner to that of RTP <xref
      target="RFC3550"></xref>. The proposals vary from once the session is
      set up; one proposal is just to use a thin shim on top of UDP or DTLS to
      de-multiplex the packets from other packets such as RTP on the same
      connection. Another proposal is DTLS over DCCP over UDP with some
      appropriate congestion control scheme chosen for DCCP. Lastly there has
      been a proposal to define a data codec to carry the data in RTP. </t>

      <t>Of all the solutions proposed to date there have been issues with
      implementation maturity and availability, congestion control, high
      overhead and NAT traversal. The solution outlined within this
      specification proposes a lightweight, simple to implement approach for
      RTC-Web client applications to transmit real-time non-media data.</t>
    </section>

    <section title="Solution Overview">
      <t>Each application datagram is send with a single byte header to help
      with de-multiplexing issues. The combined datagraph and header are sent
      either over UDP or DTLS to the receiver. The receiver sends an
      acknowledgment for every packet it receives. The sender computes a
      packet loss rate based upon the number of packets sent, and number of
      acknowledgements it has received inside of given time window. The
      browser, or other RTC-Web client application implementation, then
      enforces a maximum bandwidth usage using the TFRC-SP<xref
      target="RFC4828"></xref>. </t>

      <t>Practically this can be implemented with a simple lookup table such
      as Table 1 in <xref target="RFC4828"></xref> that limits the data rate.
      A JavaScript application running in the browser can implement more
      complex fragmentation, reliability, and congestion control algorithms,
      but it is the browser, or other RTC-Web client application, that is
      responsible for enforcing the basic congestion safety with the TFRC-SP
      algorithm.</t>
    </section>

    <section title="Specification">
      <t>When sending a datagram, a single byte with the value 62 MUST be
      prepended to the data to be sent. The data is then sent over the UDP or
      a DTLS flow that has been set up by ICE. The receiver MUST send an
      acknowledgement for each packets it receives. This acknowledgment is a
      UDP or DTLS datagram containing a single byte with the value of 63. The
      packet loss rate is computed by comparing the number of packet sent to
      the of acknowledgements received within the past 2 seconds. The packet
      loss rate and amount of data sent is used with the TFRC-SP algorithm to
      compute a maximum safe bandwidth. The sender MUST not exceed this
      bandwidth. If an application requests the browser, or other RTC-Web
      client application, to send a packet that would exceed the bandwidth,
      the RTC-Web client application MUST signal an error to the requesting
      application and drop the packet.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Because there are a number of security issues, considerations and
      requirements for RTC-WEB client applications there is a draft that
      specifically addresses the RTC-WEB application security considerations.
      This draft defers it's security considerations and requirements to the
      security considerations for RTC-Web draft <xref
      target="I-D.ekr-security-considerations-for-rtc-web"></xref>.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>You too can see your name here, just send us comments.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4828.xml'?>

      <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml'?>

      <reference anchor="I-D.ekr-security-considerations-for-rtc-web">
        <front>
          <title abbrev="RTC-Web Security">Security Considerations for
          RTC-Web</title>

          <author fullname="Eric Rescorla" initials="E.K." surname="Rescorla">
            <organization>RTFM, Inc.</organization>

            <address>
              <postal>
                <street>2064 Edgewood Drive</street>

                <city>Palo Alto</city>

                <region>CA</region>

                <code>94303</code>

                <country>USA</country>
              </postal>

              <phone>+1 650 678 2350</phone>

              <email>ekr@rtfm.com</email>
            </address>
          </author>

          <date day="30" month="May" year="2011" />

          <area>RAI</area>

          <workgroup>RTC-Web</workgroup>

          <abstract>
            <t>The Real-Time Communications on the Web (RTC-Web) working group
            is tasked with standardizing protocols for real-time
            communications between Web browsers. The two major use cases for
            RTC-Web technology are real-time audio and/or video calls and
            direct data transfer. Unlike most conventional real-time systems
            (e.g., SIP-based soft phones) RTC-Web communications are directly
            controlled by some Web server, which poses new security
            challenges. For instance, a Web browser might expose a JavaScript
            API which allows a server to place a video call. Unrestricted
            access to such an API would allow any site which a user visited to
            "bug" a user's computer, capturing any activity which passed in
            front of their camera. This document defines the RTC-Web threat
            model and defines an architecture which provides security within
            that threat model.</t>
          </abstract>

          <note title="Legal">
            <t>THIS DOCUMENT AND THE INFORMATION CONTAINED THEREIN ARE
            PROVIDED ON AN “AS IS” BASIS AND THE CONTRIBUTOR, THE
            ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE
            INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING
            TASK FORCE, DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
            BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
            THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
            MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</t>
          </note>
        </front>
      </reference>
    </references>
  </back>
</rfc>