One document matched: draft-castellani-core-coap-overhead-01.txt
Differences from draft-castellani-core-coap-overhead-00.txt
CoRE Working Group A. Castellani
Internet-Draft M. Gheda
Intended status: Informational University of Padova
Expires: September 15, 2011 March 14, 2011
CoAP overhead: protocol analysis and reduction proposals
draft-castellani-core-coap-overhead-01.txt
Abstract
This draft aims at providing an analysis of the current overhead
present in CoAP and at proposing alternative formats leading to an
even more compact procotol.
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 September 15, 2011.
Copyright Notice
Copyright (c) 2011 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.
Castellani & Gheda Expires September 15, 2011 [Page 1]
Internet-Draft CoAP overhead March 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overhead analysis . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Message ID and Token . . . . . . . . . . . . . . . . . . . 3
2.1.1. Limit Token usage . . . . . . . . . . . . . . . . . . 4
2.2. Uri-* Options . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Overhead in CoAP examples . . . . . . . . . . . . . . . . 4
3. Transport-related optimization . . . . . . . . . . . . . . . . 6
3.1. Action and Action Code . . . . . . . . . . . . . . . . . . 7
3.2. CON messages with ACK piggybacked (CONACK) . . . . . . . . 8
3.3. Multi-datagram transfers . . . . . . . . . . . . . . . . . 9
3.3.1. Link-MTU Option . . . . . . . . . . . . . . . . . . . 10
3.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . 11
4. URI optimization . . . . . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
6. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Castellani & Gheda Expires September 15, 2011 [Page 2]
Internet-Draft CoAP overhead March 2011
1. Introduction
Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] design
is focused on defining a REST protocol for constrained devices.
CoAP's strength is mainly to be a light binary REST protocol mappable
to HTTP and suitable for M2M communication.
The design of such a protocol requires a lot of effort to effectively
reduce the required overhead to a minimum, still leaving the
resulting protocol simple enought for severely limited devices to
handle it.
This document aims at highlighting possible aspects of the protocol
design not fully optimized. To the best of the authors's knowledge,
discussion about the outlined topics has not yet happened in the WG.
The document is organized as follows:
o Section 2 briefly analyzes the protocol overhead;
o Section 3 discusses alternative header formats and transport-
related optimizations;
o Section 4 describes possible URI encodings to reduce overhead
(TBD).
2. Overhead analysis
A synthetic description of the fields with higher impact on overhead
and an example follow:
o Section 2.1 briefly discusses the Message ID field and Token
Option;
o Section 2.2 outlines the overhead related Uri-* options (TBD);
o Finally, Section 2.3 analyzes the overhead allocation of a sample
CoAP exchange.
2.1. Message ID and Token
In [I-D.ietf-core-coap] two different fields are available to perform
session matching when concurrent sessions are present between the
endpoints:
o Message ID: defined in Sec. 3.1 of [I-D.ietf-core-coap]
o Token: defined in Sec. 5.10.1 of [I-D.ietf-core-coap]
The Message ID field is also intended to handle datagram duplication.
The use of the aforementioned fields introduces a total overhead
ranging between 2 and 11 bytes per message.
Castellani & Gheda Expires September 15, 2011 [Page 3]
Internet-Draft CoAP overhead March 2011
As a side note, dynamic memory allocation is usually avoided on
contrained devices. The Token Option as currently defined requires
implementors on statically allocating server devices to fully reserve
8 bytes per request for Token independently on the size chosen by the
client.
When Token option is not present, session matching rule for non-empty
messages is simple. It is sufficient to check that source and
destination address and port.
Session matching rule is more complex when Token option can be used.
If an endpoint supports the Token option, the following session
matching rules MUST be added:
o also the Token MUST be checked for every non-empty message,
because messages with a different Token belong to a different
session;
o to understand to which session belongs an empty ACK or RST message
(has no Token), the MID field in the received packet has to be
used to search which session sent a CON message with that MID.
Session matching logic can be significantly simplified by adding the
Token option to empty messages.
2.1.1. Limit Token usage
The Token option as defined in CoAP is needed to successfully match
requests to deferred responses when a client has opened more than one
concurrent session to the same server using the same UDP source port.
A client can always choose to open concurrent sessions to the same
server using different UDP source ports. Clients SHOULD avoid
sending Token option using dynamic source port assignment.
Constrained server implementation MAY not support Token option, in
order to limit memory consumption and session matching complexity.
Clients accessing these servers, in order to perform concurrent
requests to them, are required to send concurrent requests using
different source ports for each concurrent request to them.
2.2. Uri-* Options
TBD
2.3. Overhead in CoAP examples
An overhead analysis of the example present in Section 2.2 of
[I-D.ietf-core-coap] and for convenience reported hereafter in
Figure 1 follows.
Castellani & Gheda Expires September 15, 2011 [Page 4]
Internet-Draft CoAP overhead March 2011
Client Server
| |
| CON [MID=0xbc90], GET, /temperature, Token=0x71 ----->|
| |
|<--- ACK [MID=0xbc90], 2.00 OK, Token=0x71, Content=6B |
Figure 1: CoAP example
Table 1 and Table 2 analyze how the request/response bytes are
allocated to the different fields. Req1/Res1 refer to the exact
example shown in Figure 1. Req2/Res2 are referred to the same
message exchange however with smaller Uri "/t" and 2B Content; the
size of Uri/Content are under the control of the system developers
and are thus expected to be reduced when needed.
Moreover as pointed out in Section 2.1.1, clients can always avoid
using Token option by using different source UDP ports for concurrent
requests.
+---------------+--------------+--------------+--------------+
| Field(s) | Req1 (Ratio) | Req2 (Ratio) | Req3 (Ratio) |
+---------------+--------------+--------------+--------------+
| Base | 2B (0.11) | 2B (0.25) | 2B (0.33) |
| MID and Token | 4B (0.22) | 4B (0.50) | 2B (0.33) |
| URI | 12B (0.67) | 2B (0.25) | 2B (0.33) |
| Total | 18B (1.00) | 8B (1.00) | 6B (1.00) |
+---------------+--------------+--------------+--------------+
Table 1: Request size analysis
+---------------+--------------+--------------+--------------+
| Field(s) | Res1 (Ratio) | Res2 (Ratio) | Res3 (Ratio) |
+---------------+--------------+--------------+--------------+
| Base | 2B (0.17) | 2B (0.25) | 2B (0.33) |
| MID and Token | 4B (0.33) | 4B (0.50) | 2B (0.33) |
| Content | 6B (0.50) | 2B (0.25) | 2B (0.33) |
| Total | 12B (1.00) | 8B (1.00) | 6B (1.00) |
+---------------+--------------+--------------+--------------+
Table 2: Response size analysis
In Req1/Res1 results, it can be seen that Uri/Content have high
impact on the total message size, however, when optimizing their size
by using a shorter Uri and a more efficient content representation,
their impact can be substantially reduced by system developers using
CoAP (Res2/Req2).
Castellani & Gheda Expires September 15, 2011 [Page 5]
Internet-Draft CoAP overhead March 2011
If CoAP implementation avoids using Token option, the resulting CoAP
packets are even more compact (Req3/Res3).
3. Transport-related optimization
The following section discusses a proposal to reduce even more the
impact of overhead, and adding the following features to CoAP
"message"-layer:
o multi-datagram message support;
o partial reordering of unconfirmed messages.
Figure 2 shows a proposal of modification of the current CoAP header
format.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | OC |R| A | AC | SMID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Header format w/ sequence number
The definition of the fields already introduced in Figure 6 of
[I-D.ietf-core-coap] is still valid.
New fields introduced in Figure 2 are defined as follows:
Reserved field (R): 1-bit unsigned integer. This field is reserved
for future use and MUST always be set to 0. If R field is set to 1,
a RST message SHOULD be sent and the message MUST be dropped.
Action (A): 3-bit unsigned integer. Indicates whether the message is
empty (0) or is carrying a response (1-6) or a request (7). More
details about the value of this field can be found in Table 3
Action Code (AC): 4-bit unsigned integer. Indicates more details
about the kind of request (method), response (specific status)
carried in the message. If the Action is an empty message, AC field
usage is reserved for future use.
Sequential Message ID (SMID): 8-bit unsigned integer. Used to detect
duplication and to match Acknowledgment/Reset to a previous message
of type Confirmable.
SMID is a 8-bit unsigned integer that MUST be initialized on the
first message of a session. SMID is a global parameter of the
Castellani & Gheda Expires September 15, 2011 [Page 6]
Internet-Draft CoAP overhead March 2011
session shared between the endpoints. Each endpoint emitting a non-
empty message MUST echo SMID increased by 1, otherwise for empty
messages SMID value is echoed as is.
When Token option is used multiple different sessions MAY exist with
the same destination address and port. To successfully handle SMID
across multiple sessions, the Token option MUST be echoed back also
in every empty message.
3.1. Action and Action Code
The Action field contains synthetic information about message
semantics. By leveraging the information contained in the Action
field (see Table 3), CoAP implementors can scalably choose the level
of support to implement in each Action class.
Example: On extremely constrained implementations, the Action Code
can be read only for requests or for 2xx, 4xx, 5xx responses. For
other actions the effects of the message do not depend upon the
specific code received.
+-------+----------------------------+
| Value | Action |
+-------+----------------------------+
| 0 | Empty message |
| 1 | 1xx Informational response |
| 2 | 2xx Successful response |
| 3 | 3xx Redirection response |
| 4 | 4xx Client Error response |
| 5 | 5xx Server Error response |
| 6 | CoAP-specific response |
| 7 | Request |
+-------+----------------------------+
Table 3: CoAP Action values
When the action is a request, the code field will contain the details
about the method used to access the resource. The actual definition
of the Action Code values to GET, POST, PUT and DELETE methods is
out-of-scope of this document, however it can be easily obtained if
the described compressed header is believed to be suitable to the
CoAP protocol specification.
As before, the actual mapping between Action Code and specific
response codes is out-of-scope of this document, but an option for a
simple assignment could be to use "direct YY mapping", that is
deriving the value directly from YY of every response code (X.YY) as
defined in Table 6 of [I-D.ietf-core-coap].
Castellani & Gheda Expires September 15, 2011 [Page 7]
Internet-Draft CoAP overhead March 2011
"Direct YY mapping" example: 5.02 Bad Gateway can be mapped to A=5
and AC=2.
The response codes currently defined in CoAP are all mappable using
"direct YY mapping".
Even looking in [RFC2616] or in the more recent
[I-D.ietf-httpbis-p2-semantics], all HTTP status codes except two 4xx
status codes (416, 417) are mappable using "direct YY mapping".
Moreover 416 and 417 status codes are intended for responses to
complex request statements, currently out-of-scope from the CoRE
charter and otherwise manageable using different AC mappings.
3.2. CON messages with ACK piggybacked (CONACK)
Assume the following situation happens:
C S
| |
| CON |
+-------->|
| | .. some time passes ..
| ACK | Response is deferred
| X-------+ S sends an empty ACK
| |
| | .. before retransmit timer of C triggers ..
| CON | S sends the actual response in a CON message (CONACK)
|<--------+
In order to simplify client logic and to reduce overhead, the most
simple action C can do is to stop the retransmit timer and assume
that this CON message piggybacks the lost acknowledge.
Otherwise the client should keep the retransmit timer active, and
when the timer triggers, the initial request message (CON) has to be
retransmitted. The server itself MUST keep track of both active CON
messages, to be able to retransmit an empty ACK when received the
same request again and to be able to retransmit the response if no
ACK is received.
A simple solution to this problem is introducing a new logical
message type (CONACK): a CON message sent after receiving CON
message. A received CONACK message piggybacks the acknowledge to a
previously sent CON message in the same session. Before accepting
this CON message, datagram duplication MUST be checked as usual.
Castellani & Gheda Expires September 15, 2011 [Page 8]
Internet-Draft CoAP overhead March 2011
A consequence of using CONACKs is an added benefit to the protocol
itself, because a server can always decide to emit a CONACK after a
CON request, if it wants to receive an acknowledge for any sent
response.
3.3. Multi-datagram transfers
Limiting the CoAP message size to the datagram MTU can lead to some
issues and limit its range of application, as discussed in
[I-D.ietf-core-block].
[I-D.ietf-core-block] defines how to transfer large resource
representations, by introducing the Block Option and defining a
request format to get a specific part of a large resource. The Block
option allows to transfer response content fragmented in parts of
agreed size. Using this option, the client is enabled to request a
specific part of the resource representation, and the resulting
exchange is similar to subsequent HTTP Range requests (see Sec. 14.35
in [RFC2616]).
Using this approach when dealing with large resources with non-static
representations lead to an increased complexity in the upper layers,
due to the necessary controls and buffering required to avoid
transferring multiple parts belonging to different representations.
A more traditional ordered data transfer technique handles more
easily this situation, and can be built inside the CoAP "messages"-
layer depicted in Figure 1 of [I-D.ietf-core-coap].
In the following part of this section, an alternative method for
transferring segmented messages is described.
Endpoints willing to support multi-datagram transfers MAY support the
following variant. The reserved field R shown in Figure 2 can be
redefined as follows:
More datagrams pending (M): 1-bit boolean value. Indicates that the
current message is formed by other datagrams too, the endpoint
receiving this message MUST wait to receive all the datagrams before
handling it.
If the message does not fit into a single datagram, the M bit MUST be
set. After receiving an ACK message confirming the reception of each
data segment, the subsequent part fitting in a datagram should be
sent. If the sender times out waiting for an ACK, it retransmits the
same data segment.
Multi-datagram messages SHOULD be sent only using CON messages in
order to perform congestion control of any kind.
Castellani & Gheda Expires September 15, 2011 [Page 9]
Internet-Draft CoAP overhead March 2011
The SMID field present in the variant shown in Figure 2 is suitable
for multi-datagram tranfers too. SMID field MUST be increased at
every subsequent data segment sent, ACK messages MUST have SMID value
matching the SMID of the acknowledged message. The presence of this
field is useful to avoid confusing a new ACK with a network
duplicated one.
When a message is received containing the field M set to 0, the last
content segment is attached to the message, which is then passed to
the CoAP "request/response"-layer and handled.
Thanks to the half-duplex nature of a REST conversation, multi-
datagram requests and responses can be tranferred using the same
method: after sending all the request datagrams, the server handles
the request and can send all the datagrams forming the response using
this technique. The same SMID value is initially chosen and
increased by the client to send the request, and is then increased by
the server when sending back the response.
Action, Action Code and Options related to the message SHOULD be sent
only in the first datagram. To reduce overhead, the Options SHOULD
be removed from subsequent datagrams; to avoid confusion and
redundancy, Action and Action Code fields MAY be set to zero, the
presence of content in the message allows to distinguish subsequent
segments from an empty message.
3.3.1. Link-MTU Option
As noted in [I-D.ietf-core-block], the fragmentation/reassembly
process loads the lower layers. To avoid this problem multi-datagram
transfer SHOULD transfer data segments fitting in a single link layer
frame.
+------+-----+----------+-----------+--------+---------+
| Type | C/E | Name | Data type | Length | Default |
+------+-----+----------+-----------+--------+---------+
| TBD | E | Link-MTU | uint | 1-2 B | TBD |
+------+-----+----------+-----------+--------+---------+
To address situations where the sending endpoint does not know the
frame limits of the receiver, its size can be proactively shared
attaching a Link-MTU option to requests expecting big responses. To
react even more promptly, this option can be piggybacked over an
empty ACK aknowledging a fragmented message.
Castellani & Gheda Expires September 15, 2011 [Page 10]
Internet-Draft CoAP overhead March 2011
3.3.2. Example
Figure 3 shows an interaction between a CoAP Client and Server, where
both are transferring content using multi-datagram transfers.
Right after the client has completed the multi-datagram request, the
server starts replying with a multi-datagram response.
Client Server
| |
| CON [M=1,SMID=100], POST, /configuration ----------->|
| |
|<--------------------------------- ACK [M=0,SMID=100] |
| |
| CON [M=1,SMID=101] --------------------------------->|
| |
|<--------------------------------- ACK [M=0,SMID=101] |
| |
| CON [M=0,SMID=102] --------------------------------->|
| |
|<------------------------ CON [M=1,SMID=103], 2.00 OK |
| |
| ACK [M=0,SMID=103] --------------------------------->|
| |
|<--------------------------------- CON [M=1,SMID=104] |
| |
| ACK [M=0,SMID=104] --------------------------------->|
| |
|<--------------------------------- CON [M=0,SMID=105] |
| |
| ACK [M=0,SMID=105] --------------------------------->|
| |
Figure 3: Multi-datagram messaging example
Figure 3 also shows an application of CONACK. The CON message sent
by the server with SMID=103 (CONACK) piggybacks an acknowledge to the
CON message sent by the client with SMID=102.
4. URI optimization
Further discussion about URI encoding using two optional compressed
URI options will follow in a planned revision of the document.
Refer to the following message to get an idea of the encodings that
Castellani & Gheda Expires September 15, 2011 [Page 11]
Internet-Draft CoAP overhead March 2011
will be discussed:
http://www.ietf.org/mail-archive/web/core/current/msg00315.html
Discussion about the proposed encodings was partly done on the ML,
however a more complete proposal may be useful to better evaluate the
subject.
5. Acknowledgements
Special thanks to Nicola Bui and Michele Zorzi for their support and
contributions.
6. Normative References
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-04 (work in progress), January 2011.
[I-D.ietf-httpbis-p2-semantics]
Fielding, R., Gettys, J., Mogul, J., Nielsen, H.,
Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke,
"HTTP/1.1, part 2: Message Semantics",
draft-ietf-httpbis-p2-semantics-12 (work in progress),
October 2010.
[I-D.ietf-core-block]
Shelby, Z. and C. Bormann, "Blockwise transfers in CoAP",
draft-ietf-core-block-01 (work in progress), January 2011.
Authors' Addresses
Angelo P. Castellani
University of Padova
Via Gradenigo 6/B
Padova 35131
Italy
Email: angelo@castellani.net
Castellani & Gheda Expires September 15, 2011 [Page 12]
Internet-Draft CoAP overhead March 2011
Mattia Gheda
University of Padova
Via Gradenigo 6/B
Padova 35131
Italy
Email: ghedamat@dei.unipd.it
Castellani & Gheda Expires September 15, 2011 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-23 15:11:57 |