Skip to main content

CoAP option for no server-response
draft-tcs-coap-no-response-option-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7967.
Authors Abhijan Bhattacharyya , Soma Bandyopadhyay , Arpan Pal
Last updated 2013-09-06
RFC stream (None)
Formats
IETF conflict review conflict-review-tcs-coap-no-response-option, conflict-review-tcs-coap-no-response-option, conflict-review-tcs-coap-no-response-option, conflict-review-tcs-coap-no-response-option, conflict-review-tcs-coap-no-response-option, conflict-review-tcs-coap-no-response-option
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Became RFC 7967 (Informational)
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-tcs-coap-no-response-option-01
CoRE                                                   A. Bhattacharyya
Internet Draft                                         S. Bandyopadhyay
Intended status: Standards track                                 A. Pal
Expires: March 2014                      Tata Consultancy Services Ltd.
                                                      September 6, 2013

                    CoAP option for no server-response
                   draft-tcs-coap-no-response-option-01

   Abstract

   The server end-point does not respond with acknowledgment (ACK) in
   non-confirmable (NON) mode of CoAP. However, the server responds the
   client with a status code indicating "the result of the attempt to
   understand and satisfy the request". But there may be typical
   scenarios, while updating resources in NON mode, where any kind of
   response from the server may be considered redundant. Thus, in this
   case, the transaction becomes completely open-loop with no reverse
   path from the server to the client. This kind of exchange may be
   useful in constrained systems looking for maximized throughput with
   minimized resource consumption. This draft introduces a header
   option: 'No-Resp' to suppress responses from the server and
   discusses an exemplary but practical use case which actually
   motivated this proposition based on real experience. This option not
   only allows suppressing any kind of responses but allows suppressing
   a typical class or a combination of classes of responses. This
   option is applicable for both request/ response as well as resource-
   observe mode and may be effective for both unicast and multicast
   scenarios.

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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

Bhattacharyya, et al.   Expires March 6, 2014                 [Page 1]
 Internet-Draft  draft-tcs-coap-no-response-option-01    September 2013

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on March 6, 2009.

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
   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 ................................................ 3
      1.1. Motivation ............................................. 3
         1.1.1. The use case ...................................... 3
         1.1.2. Problem description ............................... 3
         1.1.3. Solution approach and proposed modification ....... 4
      1.2. Terminology ............................................ 4
   2. Achieving Granular Response-Suppression ..................... 4
   3. Option Definition ........................................... 5
   4. Example ..................................................... 6
      4.1. Request/response Scenario .............................. 6
      4.2. Resource-observe Scenario .............................. 7

Bhattacharyya, et al.   Expires March 6, 2014                 [Page 2]
 Internet-Draft  draft-tcs-coap-no-response-option-01    September 2013

   5. IANA Considerations ......................................... 8
   6. Security Considerations ..................................... 9
   7. Acknowledgments ............................................. 9
   8. References .................................................. 9
      8.1. Normative References ................................... 9

1. Introduction

   This draft proposes a new Constrained Application Protocol (CoAP)
   header option: No-Resp which suppresses responses from the server-
   endpoint. This option can be used while updating any resource in
   non-confirmable (NON) mode.

1.1. Motivation

   Introduction of this option is motivated by a practical use case as
   described in the following sub-sections.

1.1.1. The use case

   We consider tracking application in an intelligent transport system
   (ITS).

   Each vehicle in ITS is equipped with a sensor-gateway connected to
   sensors like GPS and Accelerometer. The sensor-gateway connects to
   the Internet using a low-bandwidth cellular (e.g. GPRS) connection.
   The GPS co-ordinates are periodically updated to the back-end server
   by the gateway. The update period is configurable. In case of ITS
   the update rate is adaptive to the motional-state of the vehicle. If
   the vehicle moves fast the update rate is high as the position of
   the vehicle changes rapidly. If the vehicle is static or moves
   slowly then the update rate is low. This ensures that bandwidth and
   energy is not consumed unnecessarily. The motional-state of the
   vehicle is inferred by a local analytic, running on the sensor-
   gateway, using the accelerometer data and the rate of change in GPS
   co-ordinates. The back-end server hosts applications which use the
   updates for each vehicle and produce necessary information for
   remote users.

1.1.2. Problem description

   The higher rate of update puts more load on the network-traffic and
   the load increases in proportion to the increasing number of
   vehicles in the system. Also, the higher rate of update demands more
   energy from the sensor-gateway. So we need to reduce the load on the
   network as well as the sensor-gateway.

Bhattacharyya, et al.   Expires March 6, 2014                 [Page 3]
 Internet-Draft  draft-tcs-coap-no-response-option-01    September 2013

1.1.3. Solution approach and proposed modification

   When the vehicle is moving slowly or is static, the update rate is
   low. So each flight of data to the server is important and needs to
   be delivered in a reliable manner due to sparse arrival rate. In
   this case a normal confirmable (CON) mode of update is desirable.

   When the update rate is high, any lost flight of data is soon to be
   followed by next one. Also, since the vehicle is moving very fast,
   the actual co-ordinates of the vehicle changes by the time a lost
   co-ordinate is retransmitted. So the nature of data allows us to
   tolerate stray losses. Thus the process of retransmitting
   coordinates already passed by may be deemed unnecessary as always
   lost old co-ordinates can be approximated from the new one. So, the
   system can adaptively choose to operate in NON mode. Thus, chances
   of duplicate transmission are also removed and the system becomes
   more light-weight. Thus, reliability is traded-off against
   opportunistic saving of the consumed bandwidth and energy.

   However, in NON mode, the server responds with a response code
   keeping the field for ACK blank. Thus the total bandwidth
   consumption in NON mode becomes comparable to a CON transaction
   which was successful in one go. So, even in NON mode, the client
   waits for the 4 bytes of response from the server. This waiting
   affects the latency of the system. Hence, for further optimization,
   the server status code may also be suppressed. As updates are
   frequent, so the knowledge about the execution status of the
   instantaneous update request may also be considered redundant. The
   sensor-gateway can also switch off the listening functionality as no
   response is expected. Thus the update rate is free of any dependency
   on the latency and becomes largely dependent on the limits of the
   updating device.

1.2. Terminology

   The terms used in this draft are in conformance with those defined
   in [I-D.ietf-core-coap].

   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 RFC-2119.

2. Achieving Granular Response-Suppression

   The proposed option enables the end-points, performing operations
   like update, to explicitly express disinterest in any response. Thus
   the end-point can seize the listening activity and only transmits.

Bhattacharyya, et al.   Expires March 6, 2014                 [Page 4]
 Internet-Draft  draft-tcs-coap-no-response-option-01    September 2013

   However, just as a server may perform granular suppression for group
   communication as described in Section 3.7 of [I-D.ietf-core-
   groupcomm], the clients may also explicitly define its disinterest
   on particular (or combination of) type of responses. Of course, such
   a granular selection will not allow the client to completely stop
   listening as it has to be ready whenever a response of the desired
   category arrives.

   An example requirement for such granularity may be the case where
   the updating unit needs to know if the request encounters a 'bad'
   situation falling in the 4.xx category of response code. Consecutive
   4.xx responses may lead to stopping the update.

3. Option Definition

   The properties of this option are as in Table 1.

   +--------+-----+----------------+-------------+--------+---------+
   | Number | C/E |       Name     | Data Format | Length | Default |
   +--------+-----+----------------+-------------+--------+---------+
   |   TBD  |  E  |    No-Resp     |     uint    |   3B   |  (none) |
   +--------+-----+----------------+-------------+--------+---------+
                           Table 1: Option Properties

   This option MAY be used to suppress any response or a selective
   class of response or a combination of different classes of responses
   from the server notifying the client about the execution status of
   the requested method.

   This option is defined as a bit-map to achieve granular suppression
   as defined in Table 2.

   +-------+-----------------------+---------------------------------+
   | Value | Binary Representation |       Description               |
   +-------+-----------------------+---------------------------------+
   |   7   |          111          |Suppress all classes of responses|
   +-------+-----------------------+---------------------------------+
   |   1   |          001          | Suppress 2.xx success responses |
   +-------+-----------------------+---------------------------------+
   |   2   |          010          |   Suppress 4.xx client errors   |
   +-------+-----------------------+---------------------------------+
   |   4   |          100          |   Suppress 5.xx server errors   |
   +-------+-----------------------+---------------------------------+
                          Table 2: Option values

Bhattacharyya, et al.   Expires March 6, 2014                 [Page 5]
 Internet-Draft  draft-tcs-coap-no-response-option-01    September 2013

   XOR of the values defined for suppressing particular classes will
   result into suppression of a combination of classes of response.
   Note that the option value to suppress all types of responses is XOR
   of the values for suppressing the three classes. So, a value of 3
   (binary: 011) will result in suppression of all 2.xx and 4.xx
   classes of responses.

   This option is presently defined for update requests (e.g., PUT) in
   NON mode or for non-confirmable update notifications against an
   observe request. At present it should have no effect if present with
   a CON request.

   [TBD1: Probably this option may be useful for CON mode as well in
   case of separate responses. There may be certain scenarios where the
   ACK is enough to satisfy the client application and one extra flight
   due to the separate status response may be avoided.]

4. Example

4.1. Request/response Scenario

   Figure 1 shows a typical request with this option. As described in
   section 1.1.3, the depicted scenario occurs when the nth vehicle
   moves very fast and update rate is high. The vehicle is assigned a
   dedicated resource: vehicle-stat-<n>, where <n> can be any string
   uniquely identifying the vehicle. The update requests are in NON
   mode. The No-Resp option causes the server not to reply with any
   status code.

Bhattacharyya, et al.   Expires March 6, 2014                 [Page 6]
 Internet-Draft  draft-tcs-coap-no-response-option-01    September 2013

   Client Server
   |      |
   |      |
   +----->| Header: PUT (T=NON, Code=3, MID=0x7d38)
   | PUT  | Token: 0x53
   |      | Uri-Path: "vehicle-stat-00"
   |      | Content Type: text/plain
   |      | No-Resp:7
   |      | Payload:
   |      | "VehID=00&RouteID=DN47&Lat=22.5658745&Long=88.4107966667&
   |      | Time=2013-01-13T11:24:31"
   |      |
   [No response from the server. Next update in 20 secs.]
   |      |
   +----->| Header: PUT (T=NON, Code=3, MID=0x7d39)
   | PUT  | Token: 0x54
   |      | Uri-Path: "vehicle-stat-00"
   |      | Content Type: text/plain
   |      | No-Resp:7
   |      | Payload:
   |      | "VehID=00&&RouteID=DN47Lat=22.5649015&Long=88.4103511667&
   |      | Time=2013-01-13T11:24:51"

    Figure 1: Exemplary unreliable update with no feedback path from the
                                 server.

4.2. Resource-observe Scenario

   This option can be used along with update notification from a CoAP
   server end-point against an observe request from a CoAP client end-
   point. The exemplary use case described in section 1.1.1 may be
   easily modified to apply resource-observe mode. In such a case the
   backend infrastructure acts as a client and registers its interest
   in the GPS updates from the sensor-gateway on the vehicle. So the
   gateway acts as a server. Again, following the similar reasoning of
   section 1.1.3 the device-gateway may decide to go for NON mode with
   'No-resp' option to reduce the resource usage. An example exchange
   is depicted in Figure 2.

Bhattacharyya, et al.   Expires March 6, 2014                 [Page 7]
 Internet-Draft  draft-tcs-coap-no-response-option-01    September 2013

   Server Client
   |      |
   |<-----+ Header  : GET (MID=0x5d28)
   |  GET | Token   : 0x53
   |      | Uri-Path: vehicle-stat
   |      | Observe : (empty)
   |      |
   |      |
   +----->| Header: 2.05 (T=NON, MID=0x7d38)
   | 2.05 | Token: 0x53
   |      | Content Type: text/plain
   |      | No-Resp:7
   |      | Payload:
   |      | "VehID=00&RouteID=DN47&Lat=22.5658745&Long=88.4107966667&
   |      | Time=2013-01-13T11:24:31"
   |      |
   [No response from the server. Next update in 20 secs.]
   |      |
   +----->| Header: 2.05 (T=NON, MID=0x7d39)
   | 2.05 | Token: 0x53
   |      | Content Type: text/plain
   |      | No-Resp:7
   |      | Payload:
   |      | "VehID=00&&RouteID=DN47Lat=22.5649015&Long=88.4103511667&
   |      | Time=2013-01-13T11:24:51"

    Figure 2: Exemplary unreliable update in resource-observe mode with
                     no feedback path from the server.

5. IANA Considerations

   The IANA is requested to add the following option number entries:

Bhattacharyya, et al.   Expires March 6, 2014                 [Page 8]
 Internet-Draft  draft-tcs-coap-no-response-option-01    September 2013

   +--------+-----------+----------------------------+
   | Number | Name      |          Reference         |
   +--------+-----------+----------------------------+
   |   TBD  |  No-Resp  | Section 3 of this document |
   +--------+-----------+----------------------------+

6. Security Considerations

   The No-Resp option defined in this document presents no security
   considerations beyond those in Section 11 of the base CoAP
   specification [I-D.ietf-core-coap].

7. Acknowledgments

   Thanks to Carsten Bormann, Esko Dijk and Bert Greevenbosch for their
   valuable inputs.

8. References

8.1. Normative References

   [I-D.ietf-core-coap]

   Shelby, Z., Hartke, K. and Bormann, C.,"Constrained Application
   Protocol (CoAP)", draft-ietf-core-coap-18, June 28, 2013

   [I-D.ietf-core-observe]

   Hartke, K.,"Observing Resources in CoAP", draft-ietf-core-observe-
   09, July 15, 2013

   [I-D.ietf-core-groupcomm]

   Rahman, A. and Dijk, E.,"Group Communication for CoAP", draft-ietf
   core-groupcomm-12, July 30, 2013

Bhattacharyya, et al.   Expires March 6, 2014                 [Page 9]
 Internet-Draft  draft-tcs-coap-no-response-option-01    September 2013

Authors' Addresses

   Abhijan Bhattacharyya
   Tata Consultancy Services Ltd.
   Kolkata, India

   Email: abhijan.bhattacharyya@tcs.com

   Soma Bandyopadhyay
   Tata Consultancy Services Ltd.
   Kolkata, India

   Email: soma.bandyopadhyay@tcs.com

   Arpan Pal
   Tata Consultancy Services Ltd.
   Kolkata, India

   Email: arpan.pal@tcs.com

Bhattacharyya, et al.   Expires March 6, 2014                [Page 10]