[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-greevenbosch-core-block-minimum-time) 00 01

core                                                     B. Greevenbosch
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                          April 26, 2013
Expires: October 28, 2013


                     CoAP Minimum Request Interval
          draft-greevenbosch-core-minimum-request-interval-01

Abstract

   This document defines an "Minimum-Request-Interval" option for CoAP,
   which can be used to negotiate the minimum time between two
   subsequent requests within a single client and server pair.  It can
   be used for flow and congestion control, reducing the consumption of
   server and network resources when needed.

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 October 28, 2013.

Copyright Notice

   Copyright (c) 2013 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



Greevenbosch            Expires October 28, 2013                [Page 1]


Internet-Draft       CoAP Minimum Request Interval            April 2013


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements notation . . . . . . . . . . . . . . . . . . . .   2
   3.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  The "Minimum-Request-Interval" option . . . . . . . . . . . .   4
   6.  Legacy behaviour  . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   11. Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is a
   RESTful protocol for constrained nodes and networks.

   This document defines a "Minimum-Request-Interval" option, which can
   be used to negotiate the minimum time between two subsequent requests
   within a single client and server pair.

   Negotiating the minimum time between the requests can be used to
   limit the associated traffic, thereby reducing network congestion.
   In addition, it allows constrained servers to limit the number of
   requests they receive within a certain time period, preventing them
   from becoming overloaded.

   The mechanism is especially useful for a block transaction, as
   defined in [I-D.ietf-core-block].  However it can also be used for
   other transactions involving multiple requests from the client, for
   example when the client browses the server's resources.

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 October 28, 2013                [Page 2]


Internet-Draft       CoAP Minimum Request Interval            April 2013


3.  Definitions

   transaction
      A series of request/response pairs within a unique client and
      server pair.

   block transaction
      A transaction which consists of the transfer of a single source
      using the block mechanism.

   two subsequent requests
      Two requests within a single transaction, in which one request
      follows the other request, without a third request from the
      transaction in between.

   request interval
      The time between two subsequent requests.

   request speed
      The multiplicative inverse of the request interval.

   ms
      Milliseconds or mibiseconds, depending on the implementation.

   mibisecond
      1/1024 of a second.

4.  Motivation

   It would be beneficial for the server to control the amount of
   requests it receives from the client within a certain time period.
   In this way, the server can achieve better usage of its internal
   resources, such as memory, processor load and message buffers.
   Limiting the number of incoming requests increases the reliability in
   responding to them, and decreases the chance on server overload.

   One method to reduce the client's request speed is for the server to
   delay sending its ACKs.  This indeed can slow down the client,
   especially in case the client only issues a new request after receipt
   of the ACK of the previous request.  However, it has the disadvantage
   that the server has to keep the transaction open, and needs to use
   resources for delaying the ACK that could have been used to perform
   other tasks.

   If, however, the server can explicitly signal the client's request
   speed, then the server does not need to keep track of its own minimum
   time to respond to each request, and can handle requests as soon as
   possible.  This allows the server to use its resources for other



Greevenbosch            Expires October 28, 2013                [Page 3]


Internet-Draft       CoAP Minimum Request Interval            April 2013


   tasks sooner.  Since all clients will have a better probability that
   their requests are handled and that they will receive responses, the
   overall system's reliability is increased.

5.  The "Minimum-Request-Interval" option

   +-----+---+---+---+---+--------------------+---------+------+-------+
   | No. | C | U | N | R | Name               | Format  | Leng | Defau |
   |     |   |   |   |   |                    |         | th   | lt    |
   +-----+---+---+---+---+--------------------+---------+------+-------+
   | 60  |   |   | x |   | Minimum-Request-   | (ref to | 0-2  | 0     |
   |     |   |   |   |   | Interval           | this do | B    |       |
   |     |   |   |   |   |                    | cument) |      |       |
   +-----+---+---+---+---+--------------------+---------+------+-------+

              Table 1: The "Minimum-Request-Interval" option

   The "Minimum-Request-Interval" option is an elective option, which is
   used to negotiate the minimum time in ms that a client needs to wait
   between sending two subsequent requests.

   In the remainder of this section, it is assumed that both the client
   and the server support the "Minimum-Request-Interval" option.

   If the client plans to perform a transaction consisting of multiple
   requests, it SHOULD include the "Minimum-Request-Interval" option in
   the first request of the transaction.

   The server MUST include the "Minimum-Request-Interval" option in a
   response to a request that contained a "Minimum-Request-Interval"
   option.

   If a client receives a response with the "Minimum-Request-Interval"
   option, it MUST include the "Minimum-Request-Interval" in its
   subsequent request.

   In the request, the option's value T_C is the request interval the
   client is currently using.  An exception is the first request in the
   transaction, in which case the value T_C is a proposed request
   interval.

   In a response, the option's value T_S indicates the minimum request
   interval in ms that the server can support at that particular moment.
   Depending on its workload, the server MAY increase or decrease the
   latest value of T_C to form T_S.

   The client SHALL wait at least T_S ms between sending two subsequent
   requests.  It MAY also send at a slower speed.



Greevenbosch            Expires October 28, 2013                [Page 4]


Internet-Draft       CoAP Minimum Request Interval            April 2013


   The "Minimum-Request-Interval" option has a default value 0.  A value
   T_S=0 indicates the server does not put any restrictions on the
   transaction speed.  Similiarly value T_C=0 in the first request
   indicates that the client prefers to send the following requests as
   quickly as possible.

6.  Legacy behaviour

   It is possible that either the client or server does not support the
   "Minimum-Request-Interval" 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 transaction speed.

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

   To allow the server to distinguish between a client that supports the
   "Minimum-Request-Interval" option but wants to signal T_C=0, and a
   client that does not support the "Minimum-Request-Interval" option,
   it is RECOMMENDED for the compliant client to include the option in
   the requests of a multiple request transaction, even when the client
   wants to signal T_C=0.

7.  Example

   Figure 1 contains an example of a block transaction with the
   "Minimum-Request-Interval" option.

   In the first request, the client proposes a minimum request interval
   of T_C=150ms.  As the server is too busy, it wants to slow down the
   client and returns a minimum request interval of T_S=200ms.

   The client uses this request interval for the timing of the next
   requests, and keeps informing the server of its current request
   speed.  Likewise, in the first several messages the server echos the
   T_C in T_S, signalling that it is comfortable with the current
   request speed.

   After sending three blocks, the server becomes less busy.  It
   therefore increases the allowed request speed by signalling a new
   T_S=150ms.  The client uses this speed until the end of the
   transaction.

        CLIENT                                                 SERVER
           |                                                     |
     /     | CON [MID=1234], GET, /status, N=0, T_C=150 -------> |
     |     |                                                     |



Greevenbosch            Expires October 28, 2013                [Page 5]


Internet-Draft       CoAP Minimum Request Interval            April 2013


   200ms   | <------- ACK [MID=1234], 2.05 Content, N=0, T_S=200 |
     |     |                                                     |
     \  /  | CON [MID=1235], GET, /status, N=1, T_C=200 -------> |
        |  |                                                     |
      200ms| <------- ACK [MID=1235], 2.05 Content, N=1, T_S=200 |
        |  |                                                     |
     /  \  | CON [MID=1234], GET, /status, N=2, T_C=200 -------> |
     |     |                                                     |
   200ms   | <------- ACK [MID=1234], 2.05 Content, N=2, T_S=200 |
     |     |                                                     |
     \  /  | CON [MID=1235], GET, /status, N=3, T_C=200 -------> |
        |  |                                                     |
      150ms| <------- ACK [MID=1235], 2.05 Content, N=3, T_S=150 |
        |  |                                                     |
     /  \  | CON [MID=1234], GET, /status, N=4, T_C=150 -------> |
     |     |                                                     |
   150ms   | <------- ACK [MID=1234], 2.05 Content, N=4, T_S=150 |
     |     |                                                     |
     \     | CON [MID=1235], GET, /status, N=5, T_C=150 -------> |
           :                                                     :
           :                        ...                          :
           :                                                     :

     Figure 1: Example of transaction with "Minimum-Request-Interval"

8.  Security Considerations

   By modifying the value of the "Minimum-Request-Interval" option in a
   response to a higher value, a man-in-the-middle could increase the
   time used to perform a transaction.  When the client encounters a
   response with a too high "Minimum-Request-Interval" 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 "Minimum-Request-Interval" option in a
   response, the man-in-the-middle can induce the client to send
   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 "Minimum-Request-Interval" option.

   By altering the value of the "Minimum-Request-Interval" option in a
   request, the man-in-the-middle can induce the server to believe that
   the client is using another transaction speed than it really is.
   This could lead to a false adjustment of the request interval.





Greevenbosch            Expires October 28, 2013                [Page 6]


Internet-Draft       CoAP Minimum Request Interval            April 2013


   All these attacks depend on the man-in-the-middle being able to
   modify multiple messages, as the speed would otherwise stabilise
   again after several adjustments by the server.

9.  IANA Considerations

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

   +-----+---+---+---+---+--------------------+---------+------+-------+
   | No. | C | U | N | R | Name               | Format  | Leng | Defau |
   |     |   |   |   |   |                    |         | th   | lt    |
   +-----+---+---+---+---+--------------------+---------+------+-------+
   | 60  |   |   | x |   | Minimum-Request-   | (ref to | 0-2  | 0     |
   |     |   |   |   |   | Interval           | this do | B    |       |
   |     |   |   |   |   |                    | cument) |      |       |
   +-----+---+---+---+---+--------------------+---------+------+-------+


10.  Acknowledgements

   The author would like to thank Carsten Borrman, Esko Dijk and Kepeng
   Li for their feedback.

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-coap]
              Shelby, Z., Hartke, K., and C. Bormann, "Constrained
              Application Protocol (CoAP)", draft-ietf-core-coap-15
              (work in progress), April 2013.

   [I-D.ietf-core-block]
              Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP",
              draft-ietf-core-block-11 (work in progress), March 2013.

Author's Address












Greevenbosch            Expires October 28, 2013                [Page 7]


Internet-Draft       CoAP Minimum Request Interval            April 2013


   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 October 28, 2013                [Page 8]


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