<?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" docName="draft-thomson-tram-turn-bandwidth-01">
  <front>
    <title abbrev="TURN Bandwidth">
      A Bandwidth Attribute for TURN 
    </title>

    <author initials="M" surname="Thomson" fullname="Martin Thomson">
      <organization>Mozilla</organization>
      <address>
        <postal>
          <street>331 E Evelyn Street</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94041</code>
          <country>USA</country>
        </postal>
        <phone>+1 650-353-1925</phone>
        <email>martin.thomson@gmail.com</email>
      </address>
    </author>

    <author initials="B" surname="Aboba" fullname="Bernard Aboba">
      <organization>Microsoft</organization>
      <address>
        <postal>
          <street>One Microsoft Way</street>
          <city>Redmond</city>
          <region>WA</region>
          <code>98052</code>
          <country>USA</country>
        </postal>
        <email>bernard_aboba@outlook.com</email>
      </address>
    </author>
    
        <author fullname="Alan Johnston" initials="A."
            surname="Johnston">
      <organization>Avaya</organization>

      <address>
        <postal>
          <street></street>
          <city>St. Louis</city>
          <region>MO</region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>alan.b.johnston@gmail.com</email>
      </address>
    </author>
    
            <author fullname="Oleg Moskalenko" initials="O."
            surname="Moskalenko">
      <organization>public project rfc5766-turn-server</organization>

      <address>
        <postal>
          <street></street>
          <city>Walnut Creek</city>
          <region>CA</region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>mom040267@gmail.com</email>
        <uri>https://code.google.com/p/rfc5766-turn-server/</uri>
      </address>

    </author>

    <date year="2014"/>
    <area>RAI</area>
    <workgroup>TRAM</workgroup>
    <keyword>bandwidth</keyword>
    <keyword>negotiation</keyword>
    <keyword>TURN</keyword>

    <abstract>
      <t>
An attribute is defined for Session Traversal Utilities for NAT (STUN) that allows for declarations of bandwidth limits on the negotiated flow.  The application of this attribute is the negotiation of bandwidth between a Traversal Using Relays around NAT (TURN) client and a TURN server.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>
      
      </t>

      <t>This document defines a BANDWIDTH attribute that can be used to request and allocate bandwidth at a Traversal Using Relays around NAT (TURN) relay <xref target="RFC5766" />.
      </t>
      <t>
      The operator of a TURN server will likely wish to provide fairness between relayed sessions.  A TURN server might also wish to limit the use of service to audio-only sessions, or low bandwidth video and audio sessions.  In addition, the server may apply rate-limiting policy depending on the credential used for authentication, or the origin of the client.  Without the BANDWIDTH attribute, there is no way for a client to indicate the expected bandwidth utilization, or for the server to indicate the maximum bandwidth utilization allowed before rate limiting could be applied.
      </t>
      <t>This attribute is used for indicating a bandwidth limit that is set in policy.  The sender is not advised or required to utilize bandwidth up to this limit; limits are usually set well in excess of application needs.  Senders also limit their use of bandwidth in reaction to path congestion and "circuit breakers".
      </t>
    
    <t>Note that the BANDWIDTH attribute was originally in the TURN draft up to version draft-ietf-behave-turn-07 where it was removed as "the requirements for this feature were not clear and it was felt the feature could be easily added later."  This draft proposes adding this attribute back into TURN.  A related error code 507 "Insufficient Bandwidth Capacity" was also defined in the TURN Internet-Draft, but is not proposed in this draft.  This attribute has also been proposed to be used by ICE to provide communication consent <xref target="I-D.thomson-mmusic-rtcweb-bw-consent" />.  No use cases have been identified where bandwidth information is useful for a STUN server which is responding to STUN binding requests.
      </t>
      <t>
      There have been discussions about what other media-related information could be usefully exchanged between a TURN client and a TURN server.  One proposal was for the actual media type (voice, video, data) to be exchanged.  Other proposals include more granularity over the bandwidth, including max, min, average, etc.  While these could be added, the authors do not feel the use cases for these data have been sufficiently developed yet.  Also, this information is known in signaling through the SDP attributes and parameters.  In a particular implementation, it could be possible for a signaling-aware entity to share this information with a TURN server in order to apply policy for the media relay.
      </t>

    </section>
    <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>

      <t>The terms client, server, and peer are those used for TURN, as defined in <xref target="RFC5766"/>.
      </t>

    </section>

    <section title="The BANDWIDTH Attribute">
      <t>The BANDWIDTH attribute (identifier TBD) identifies the rate of packet transmission in kilobits per second that is permitted for a given transport flow.   The BANDWIDTH attribute is a comprehension-optional attribute (see Section 15 from <xref target="RFC5389"/>).  <xref target="attribute"/> shows the format of this attribute.
      </t>

      <figure anchor="attribute" title="Bandwidth Attribute Format">
<artwork><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Attribute Type (TBD)      |          Length (4)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Bandwidth                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
      <t>The value of this attribute is an unsigned integer that represents the maximum bandwidth for the flow in kilobits per second (1 kilobit = 1024 bits).  This is the original format of the Bandwidth attribute.  This format could include a maximum and average bandwidth, as the BANDWIDTH-USAGE attribute proposed in <xref target="I-D.martinsen-tram-discuss" />.</t>
    </section>

    <section title="Applications">
    
      <t>This section discusses the application of the BANDWIDTH attribute for STUN, TURN, and ICE.
      </t>

      <section title="STUN Usage">
      <t>Since the bandwidth of a communications session has no bearing on a STUN server that simply responds to binding requests, this attribute MUST NOT be used for client-server STUN requests or responses.
        </t>
      </section>
           <section title="TURN Usage">
        <t>This attribute can be useful for communication between a TURN client and a TURN server.
        </t><t>
        The BANDWIDTH attribute indicates a limit to available bandwidth for <xref target="RFC5766">TURN</xref> allocation.  The bandwidth limit is symmetric; the value covers the bandwidth of data sent from a peer toward the TURN server and the bandwidth of data sent from client to the TURN server.
        </t>

        <t>A BANDWIDTH attribute MAY be present in an Allocate request.  This attribute indicates that the given bandwidth is requested.  A BANDWIDTH attribute MAY be present in an Allocate response.  This attribute in a response indicates the limit that will be applied by the TURN server.  The value a TURN server provides could be influenced by the value that a TURN client requests at the discretion of server policy.  A client could use this bandwidth limitation of the TURN server in choosing media types or in choosing codecs for a media session.

        </t>
      </section>
            <section title="ICE Usage">
      <t>While <xref target="I-D.thomson-mmusic-rtcweb-bw-consent" /> proposed the use of the BANDWIDTH attribute to provide bandwidth consent for ICE, this draft does not do so.  This attribute MUST NOT be used with ICE.
        </t>
      </section>
    </section>

    <section title="Bandwidth Measurement Considerations">
    
    
      <t>Allocation messages (Binding and Allocate) sent to and from the TURN server are exempt from any bandwidth measurement accounting.   
      </t>

      <t>In calculating bandwidth, the entire IP packet - including the header - is measured.  This is identical to the measurement performed by <xref target="RFC3550">the Real-time Transport Protocol (RTP)</xref>.  At a TURN server, bandwidth measurement is performed on the packets arriving at or leaving from the TURN server, prior to the encapsulation that occurs between TURN server and TURN client.  
      </t>

      <t>Determining the rate requires that the bits be allocated to specific intervals of time.  How bits are allocated MAY vary between implementations.
      </t>

      <t>Measurement of bandwidth is imperfect and inconsistent.  Packet jitter can result in fluctuations in received packet rate so that a receiver might see an instantaneous bandwidth that is different to what the sender might have transmitted.  Jitter can cause the observed bandwidth of incoming packets to temporarily increase above the permitted rate.  At a minimum, implementations SHOULD allow for short periods of excessive bandwidth to allow for these temporary increases.
      </t>

      <section title="Rate Enforcement">
        <t>
        Enforcement of limits by the TURN server SHOULD provide an allowance for application usages that temporarily exceed the limit.  For example, assessing observed bandwidth usage as an average over 10 seconds ensures that real-time video does not clip unnecessarily; shorter durations could result in the enforcement affecting valuable intra-frames.
        </t>
      </section>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>For STUN requests or responses that are not sent using TLS or DTLS transport, the bandwidth information contained in the BANDWIDTH attribute will be available to an eavesdropper who could use it to learn about the nature of a session to be established. For example, they might be able to deduce from the bandwidth requested that the session is likely to be audio only, or audio and video.  However, an on-path attacker can likely learn this same information from either the signaling channel or by inspecting the RTP packet headers, which are in the clear for SRTP, or simply by measuring the media bandwidth used.
            </t>
            <t>If a STUN request or response is transported using TCP or UDP, the BANDWIDTH attribute will have integrity protection from the MESSAGE-INTEGRITY attribute if the request is authenticated using the STUN short-term or long-term authentication method.   Unauthenticated TCP or UDP requests will not have integrity protection and could be modified by a MitM attacker.  The use of DTLS transport <xref target="I-D.ietf-tram-stun-dtls" /> provides integrity protection for the BANDWIDTH attribute regardless of the STUN authentication method used.
            </t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>The STUN BANDWIDTH attribute uses the TBD value in the comprehension-optional range.  This attribute is registered in the "STUN Attribute" Registry following the procedures of Section 18.2 of <xref target="RFC5389"/>.
      </t>
    </section>
<section title="Implementation Status">
<t>
Note to RFC Editor: Please remove this entire section prior to publication, including the reference to RFC 6982.
</t>
<t>
This section records the status of known implementations of the
      protocol defined by this specification at the time of posting of
      this Internet-Draft, and is based on a proposal described in <xref target="RFC6982" />.  The description of implementations in this section is
      intended to assist the IETF in its decision processes in
      progressing drafts to RFCs.  Please note that the listing of any
      individual implementation here does not imply endorsement by the
      IETF.  Furthermore, no effort has been spent to verify the
      information presented here that was supplied by IETF contributors.
      This is not intended as, and must not be construed to be, a
      catalog of available implementations or their features.  Readers
      are advised to note that other implementations may exist.
</t>
<t>
      According to <xref target="RFC6982" />, "this will allow reviewers and working
      groups to assign due consideration to documents that have the
      benefit of running code, which may serve as evidence of valuable
      experimentation and feedback that have made the implemented
      protocols more mature.  It is up to the individual working groups
      to use this information as they see fit".
</t>
<t>
A multiple realms capable advanced open source TURN server (named 'Coturn') has been created by Oleg Moskalenko and is freely licensed under the New BSD license.  This reference implementation and proof-of-concept provides a clone (a spin-off) of the rfc5766-turn-server project adding STUN BANDWIDTH attribute support, among other TRAM Working Group STUN and TURN extensions.
 </t>
<t>
'Coturn' is backward-compatible with rfc5766-turn-server project but the code is more complex and it uses a different (also more complex) database structure.  It is the intent to add all IETF TRAM TURN server related capabilities to this project as they mature.  'Coturn' is publicly available and can be found at: https://code.google.com/p/coturn/
</t>
</section>

  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.5389"?>
      <?rfc include="reference.RFC.5766"?>
      <?rfc include="reference.RFC.5245"?>
      <?rfc include="reference.I-D.ietf-tram-stun-dtls"?>

    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.3550"?>
      <?rfc include="reference.I-D.thomson-mmusic-rtcweb-bw-consent"?>
      <?rfc include="reference.I-D.martinsen-tram-discuss"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6982.xml"?>
    </references>
  </back>

</rfc>