[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits] [IPR]

Versions: 00 draft-greevenbosch-core-minimum-request-interval

core                                                     B. Greevenbosch
Internet-Draft                                       Huawei Technologies
Intended status: Informational                              July 9, 2012
Expires: January 10, 2013


                        CoAP Minimum Block Time
             draft-greevenbosch-core-block-minimum-time-00

Abstract

   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.





































Greevenbosch            Expires January 10, 2013                [Page 1]


Internet-Draft           CoAP Minimum Block Time               July 2012


Note

   Discussion and suggestions for improvement are requested, and should
   be sent to core@ietf.org.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 10, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.















Greevenbosch            Expires January 10, 2013                [Page 2]


Internet-Draft           CoAP Minimum Block Time               July 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  5
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  The "MinimumBlockTime" option  . . . . . . . . . . . . . . . .  7
   5.  Legacy behaviour . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Open issues  . . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   11. Normative References . . . . . . . . . . . . . . . . . . . . . 14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15





































Greevenbosch            Expires January 10, 2013                [Page 3]


Internet-Draft           CoAP Minimum Block Time               July 2012


1.  Introduction

   The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is a
   RESTful protocol for constrained nodes and networks.  In
   [I-D.ietf-core-block], the block mechanism for block-wise
   transmission of data is defined.

   This document defines a "MinimumBlockTime" option, which can be used
   to negotiate the minimum time between two subsequent block requests.

   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.




































Greevenbosch            Expires January 10, 2013                [Page 4]


Internet-Draft           CoAP Minimum Block Time               July 2012


2.  Requirements notation

   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 [RFC2119].














































Greevenbosch            Expires January 10, 2013                [Page 5]


Internet-Draft           CoAP Minimum Block Time               July 2012


3.  Definitions

   Block transaction
      The block-wise transmission of a single resource, between a unique
      client and server pair.

   Two subsequent requests
      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.

   Block time
      The time between two subsequent requests in a block transaction.

   Block speed
      The multiplicative inverse of the block time.
































Greevenbosch            Expires January 10, 2013                [Page 6]


Internet-Draft           CoAP Minimum Block Time               July 2012


4.  The "MinimumBlockTime" option

       +------+-----+------------------+--------+--------+---------+
       | Type | C/E |       Name       | Format | Length | Default |
       +------+-----+------------------+--------+--------+---------+
       |  TBD |  E  | MinimumBlockTime |  uint  |  0-2B  |    0    |
       +------+-----+------------------+--------+--------+---------+

                  Table 1: The "MinimumBlockTime" option

   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.

   In the remainder of this section, it is assumed that both the client
   and the server support the "MinimumBlockTime" option.

   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.

   In a block request, the option's value T_C indicates the minimum
   block time in ms that the client can support.

   In a block response, the option's value T_S indicates the minimum
   block time in ms that the server can support.

   The client SHALL wait at least T_S ms between sending two subsequent
   block requests.

   The following MUST hold: T_S <= T_C.

   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.













Greevenbosch            Expires January 10, 2013                [Page 7]


Internet-Draft           CoAP Minimum Block Time               July 2012


5.  Legacy behaviour

   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.

   In either case, or their combination, the client will choose the
   block speed as it prefers.  This corresponds to the case T_S=0.

   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.


































Greevenbosch            Expires January 10, 2013                [Page 8]


Internet-Draft           CoAP Minimum Block Time               July 2012


6.  Open issues

   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.














































Greevenbosch            Expires January 10, 2013                [Page 9]


Internet-Draft           CoAP Minimum Block Time               July 2012


7.  Example

   Figure 1 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.


           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              ----> |
              :                                                      :
              :                         ...                          :
              :                                                      :

         Figure 1: Example of transaction with "MinimumBlockTime"






















Greevenbosch            Expires January 10, 2013               [Page 10]


Internet-Draft           CoAP Minimum Block Time               July 2012


8.  Security Considerations

   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.

   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.




































Greevenbosch            Expires January 10, 2013               [Page 11]


Internet-Draft           CoAP Minimum Block Time               July 2012


9.  IANA Considerations

   This draft adds the following option numbers to the CoAP Option
   Numbers registry of [I-D.ietf-core-coap].

             +----------------+------------------+-----------+
             |     Number     |       Name       | Reference |
             +----------------+------------------+-----------+
             | TBD (elective) | MinimumBlockTime | [RFCXXXX] |
             +----------------+------------------+-----------+

                       Table 2: CoAP option numbers







































Greevenbosch            Expires January 10, 2013               [Page 12]


Internet-Draft           CoAP Minimum Block Time               July 2012


10.  Acknowledgements

   The author would like to thank Kepeng Li for his ideas and feedback.
















































Greevenbosch            Expires January 10, 2013               [Page 13]


Internet-Draft           CoAP Minimum Block Time               July 2012


11.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [I-D.ietf-core-block]
              Shelby, Z. and C. Bormann, "Constrained Application
              Protocol (CoAP)", draft-ietf-core-block-08 (work in
              progress), February 2012.

   [I-D.ietf-core-coap]
              Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
              "Constrained Application Protocol (CoAP)",
              draft-ietf-core-coap-10 (work in progress), March 2012.





































Greevenbosch            Expires January 10, 2013               [Page 14]


Internet-Draft           CoAP Minimum Block Time               July 2012


Author's Address

   Bert Greevenbosch
   Huawei Technologies Co., Ltd.
   Huawei Industrial Base
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Phone: +86-755-28978088
   Email: bert.greevenbosch@huawei.com








































Greevenbosch            Expires January 10, 2013               [Page 15]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/