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]