CoRE A. Bhattacharyya
Internet Draft S. Bandyopadhyay
Intended status: Standards track A. Pal
Expires: February 2014 Tata Consultancy Services Ltd.
August 29, 2013
CoAP option for no server-response
draft-tcs-coap-no-response-option-00.txt
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 any response from the server and
discusses an exemplary but practical use case which actually
motivated this proposition based on real experience.
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."
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.
Bhattacharyya, et al. Expires February 29, 2014 [Page 1]
Internet-Draft draft-tcs-coap-no-response-option-00 August 2013
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 February 29, 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........ 3
1.2. Terminology ............................................ 4
2. Option Definition ........................................... 4
3. Example ..................................................... 5
4. IANA Considerations ......................................... 6
5. Security Considerations...................................... 6
6. References .................................................. 7
6.1. Normative References.................................... 7
Bhattacharyya, et al. Expires February 29, 2014 [Page 2]
Internet-Draft draft-tcs-coap-no-response-option-00 August 2013
1. Introduction
This draft proposes a new Constrained Application Protocol (CoAP)
header option: No-Resp which suppresses any response 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.
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.
Bhattacharyya, et al. Expires February 29, 2014 [Page 3]
Internet-Draft draft-tcs-coap-no-response-option-00 August 2013
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 id 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. Option Definition
+--------+-----+----------------+-------------+--------+---------+
| Number | C/E | Name | Data Format | Length | Default |
+--------+-----+----------------+-------------+--------+---------+
| TBD | E | No-Resp | empty | 0B | (none) |
+--------+-----+----------------+-------------+--------+---------+
Table 1: Option Properties
The properties of this option are as in Table 1. This option MAY be
used to suppress any response from the server notifying the client
about the execution status of the requested method. This option is
Bhattacharyya, et al. Expires February 29, 2014 [Page 4]
Internet-Draft draft-tcs-coap-no-response-option-00 August 2013
presently defined for update requests (e.g., PUT) in NON mode. 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.]
[TBD2: What about the scenarios when something bad happens against
the request from the client persistently? For example: may be the
request becomes a "BAD REQUEST" or the request method is "NOT
ALLOWED" or the resource is "NOT FOUND"! Under such circumstances
the client should take appropriate action rather than being ignorant
about the 'bad' status and keep on sending the update request. Then
it will be really inefficient in terms of resource savings. One way
could be to make this option conditional such that the response is
suppressed only if things do not go wrong as mentioned above. But in
that case the client cannot switch off the listening activity as
described earlier. May be we can keep this issue open assuming that
this option will be preferably used in a controlled, dedicated
infrastructure where these kind of situations are not expected
unless there is a server crash.]
3. Example
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 February 29, 2014 [Page 5]
Internet-Draft draft-tcs-coap-no-response-option-00 August 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
| | 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
| | 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. IANA Considerations
The IANA is requested to add the following option number entries:
+--------+-----------+----------------------------+
| Number | Name | Reference |
+--------+-----------+----------------------------+
| TBD | No-Resp | Section 2 of this document |
+--------+-----------+----------------------------+
5. 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].
Bhattacharyya, et al. Expires February 29, 2014 [Page 6]
Internet-Draft draft-tcs-coap-no-response-option-00 August 2013
6. References
6.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
Bhattacharyya, et al. Expires February 29, 2014 [Page 7]
Internet-Draft draft-tcs-coap-no-response-option-00 August 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 February 29, 2014 [Page 8]