One document matched: draft-greevenbosch-core-block-minimum-time-00.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'[
<!ENTITY RFC2119 SYSTEM
"/IETF/xml2rfc-1.35/bibxml/reference.RFC.2119.xml">
]>


<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>

<rfc category="info" ipr="trust200902" docName="draft-greevenbosch-core-block-minimum-time-00">
  <front>
    <title abbrev="CoAP Minimum Block Time">CoAP Minimum Block Time</title>
    <author initials="B." surname="Greevenbosch" fullname="Bert Greevenbosch">
      <organization abbrev="Huawei Technologies">Huawei Technologies Co., Ltd.</organization>
      <address>
        <postal>
          <street>Huawei Industrial Base</street>
          <street>Bantian, Longgang District</street>
          <city>Shenzhen</city>
          <code>518129</code>
          <country>P.R. China</country>
        </postal>
        <phone>+86-755-28978088</phone>
        <email>bert.greevenbosch@huawei.com</email>
      </address>
    </author>
    <date month="July" year="2012"/>
    <area>Applications</area>
    <workgroup>core</workgroup>
    <abstract>
      <t>
         This document defines an "MinimumBlockTime" option for CoAP,
         which can be used to negotiate the minimum time between two subsequent block requests.
         It can be used for overload and congestion control.
      </t>
    </abstract>
    <note title="Note">
      <t>
        Discussion and suggestions for improvement are requested, 
        and should be sent to core@ietf.org.
      </t>
    </note>
  </front>
  <middle>
    <section title="Introduction">
       <t>
          The Constrained Application Protocol (CoAP) <xref target="I-D.ietf-core-coap"/> is a RESTful protocol for constrained nodes 
          and networks.           
          In <xref target="I-D.ietf-core-block"/>, 
          the block mechanism for block-wise transmission of data is defined.
       </t>
       <t>
          This document defines a "MinimumBlockTime" option,
          which can be used to negotiate the minimum time between two subsequent block requests. 
       </t>
       <t>
          Negotiating the minimum time between the block requests can be used to limit the associated traffic,
          providing a mechanism for congestion control.
          In addition,
          it allows very constrained servers to limit the number of requests they receive within a certain time period,
          preventing them from becoming overloaded.
       </t>
    </section>
    <section title="Requirements notation">
      <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"/>.
      </t>
    </section>
    <section title="Definitions">
      <t>
        <list style="hanging">
          <t hangText="Block transaction"><vspace/>
            The block-wise transmission of a single resource,
            between a unique client and server pair.
          </t>
          <t hangText="Two subsequent requests"><vspace/>
            In this document,
            the phrase "two subsequent requests" indicates two requests in a same block transaction,
            in which one follows the other,
            without other requests from the same block transaction in between.
            Notice that the difference between the block numbers of the two subsequent requests does not have to be one,
            although most often this will be the case.  
          </t>
          <t hangText="Block time"><vspace/>
            The time between two subsequent requests in a block transaction.
          </t>
          <t hangText="Block speed"><vspace/>            
            The multiplicative inverse of the block time. 
          </t>
        </list>
      </t>
    </section>    
    <section title="The "MinimumBlockTime" option">      

      <texttable anchor="table_ex" title="The "MinimumBlockTime" option">
        <ttcol align='center'>Type</ttcol>
        <ttcol align='center'>C/E</ttcol>
        <ttcol align='center'>Name</ttcol>
        <ttcol align='center'>Format</ttcol>
        <ttcol align='center'>Length</ttcol>
        <ttcol align='center'>Default</ttcol>
        <c>TBD</c>
        <c>E</c>
        <c>MinimumBlockTime</c>
        <c>uint</c>
        <c>0-2B</c>
        <c>0</c>
      </texttable>
      <t>
        The "MinimumBlockTime" option is an elective option,
        which is used to negotiate the minimum time in milliseconds that a client needs to wait between sending two subsequent block requests.
      </t>      
      <t>
        In the remainder of this section,
        it is assumed that both the client and the server support the "MinimumBlockTime" option.
      </t>      
      <t>
        If the client includes a "Block1" or "Block2" option in its first request in a block transaction,
        it SHOULD include the "MinimumBlockTime" option in that first request too.
        The server SHOULD include the "MinimumBlockTime" option in its first block response.
      </t>
      <t>
        In a block request,
        the option's value T_C indicates the minimum block time in ms that the client can support.
      </t>
      <t>
        In a block response,
        the option's value T_S indicates the minimum block time in ms that the server can support.
      </t>
      <t>
        The client SHALL wait at least T_S ms between sending two subsequent block requests. 
      </t>
      <t>
        The following MUST hold:
        T_S <= T_C.
      </t>
      <t>
        The "MinimumBlockTime" option has a default value 0.
        A value T_S=0 indicates the server does not put any restrictions on the block speed.        
        A value T_C=0 indicates that the client prefers to send the requests as quickly as possible.
      </t>
    </section>
    
    <section title="Legacy behaviour">
      <t>
        It is possible that either the client or server does not support the "MinimumBlockTime" option.
        If the client does not support the option,
        then obviously it cannot take the server's preference into account.
        Similarly if the server does not support the option,
        it cannot use it to restrict the block speed.
      </t>
      <t>
        In either case,
        or their combination,
        the client will choose the block speed as it prefers.
        This corresponds to the case T_S=0.         
      </t>
      <t>
        To allow the server to distinguish between a client that supports the "MinimumBlockTime" option but wants to signal T_C=0,
        and a client that does not support the "MinimumBlockTime" option,
        it is RECOMMENDED for the compliant client to include option in the first request in a Block transaction,
        even when the client wants to signal T_C=0.         
      </t>
    </section>
    
    <section title="Open issues">
      <t>
         For longer block transactions,
         there may be value in allowing updates of the block speed during a block transaction.
         We should consider whether increasing efficiency will justify the extra complexity.
      </t>
    </section>
    
    <section title="Example">
      <t>
         <xref target="exampleFig"/> contains an example of a block transaction with the "MinimumBlockTime" option.         
         The client indicates its supported minimum block time as 200ms.
         The associated block speed is too high for the server,
         so the server indicates a minimum block time of 300ms.
         The client obeys this value for the rest of the transaction.
      </t>
      <t>
         <figure title="Example of transaction with "MinimumBlockTime"" anchor="exampleFig">
           <artwork align="center">
     CLIENT                                                 SERVER
        |                                                      |
  /     | CON [MID=1234], GET, /status, N=0, T_C = 200   ----> |
  |     |                                                      |
300ms   | <----   ACK [MID=1234], 2.05 Content, N=0, T_S = 300 |
  |     |                                                      |
  \  /  | CON [MID=1235], GET, /status, N=1              ----> |
     |  |                                                      |
   300ms| <----   ACK [MID=1235], 2.05 Content, N=1            |
     |  |                                                      |
  /  \  | CON [MID=1234], GET, /status, N=2              ----> |
  |     |                                                      |
300ms   | <----  ACK [MID=1234], 2.05 Content, N=2             |
  |     |                                                      |
  \     | CON [MID=1235], GET, /status, N=3              ----> |
        :                                                      :
        :                         ...                          :
        :                                                      :
            </artwork>
         </figure>
      </t>   
    </section>
    <section title="Security Considerations">
       <t>
          By modifying the value of the "MinimumBlockTime" option to a higher value,
          a man-in-the-middle could increase the time used to perform a block transaction.
          When the client encounters a response with a too high "MinimumBlockTime" value,
          it MAY abort the transaction,
          and try to reinitiate it.
          However,
          to prevent overloading the server,
          the client MUST limit the number of these reinitiations.
       </t>
       <t>          
          By decreasing the value of the "MinimumBlockTime" option,
          the man-in-the-middle can induce the client to send block requests at a speed too high for the server.
          The server should be prepared for this,
          for example by discarding requests that cannot be processed.
          This is similar to the case where the server or client does not support the "MinimumBlockTime" option. 
       </t>
    </section>
    <section title="IANA Considerations">
      <t>
         This draft adds the following option numbers to the CoAP Option Numbers registry of <xref target="I-D.ietf-core-coap"/>.
      </t>
      <texttable title="CoAP option numbers" anchor="optNo">
        <ttcol align='center'>Number</ttcol>
        <ttcol align='center'>Name</ttcol>
        <ttcol align='center'>Reference</ttcol>
        <c>TBD (elective)</c>
        <c>MinimumBlockTime</c>
        <c>[RFCXXXX]</c>
      </texttable>
    </section>
    <section title="Acknowledgements">
       <t>
          The author would like to thank Kepeng Li for his ideas and feedback. 
       </t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
       &RFC2119;
       <reference anchor="I-D.ietf-core-block">
         <front>
           <title>Constrained Application Protocol (CoAP)</title>
           <author initials="Z." surname="Shelby"/>
           <author initials="C." surname="Bormann"/>
           <date month="February" year="2012"/>
         </front>
         <seriesInfo name="draft-ietf-core-block-08" value="(work in progress)" />
       </reference>
       <reference anchor="I-D.ietf-core-coap">
         <front>
           <title>Constrained Application Protocol (CoAP)</title>
           <author initials="Z." surname="Shelby"/>
           <author initials="K." surname="Hartke"/>
           <author initials="C." surname="Bormann"/>
           <author initials="B." surname="Frank"/>
           <date month="March" year="2012"/>
         </front>
         <seriesInfo name="draft-ietf-core-coap-10" value="(work in progress)" />
       </reference>
    </references>
    
  </back>

</rfc>