LWIG Working Group A. Castellani Internet-Draft University of Padova Intended status: Informational March 26, 2012 Expires: September 27, 2012 Learning CoAP separate responses by examples draft-castellani-lwig-coap-separate-responses-00 Abstract This draft aims at providing interesting examples of CoAP separate responses that are useful to aid CoAP implementers on understanding possible rare situation incurring. 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 27, 2012. Copyright Notice Copyright (c) 2012 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 Expires September 27, 2012 [Page 1] Internet-Draft Examples of CoAP Separate Responses March 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Taxonomy of cases . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Request lost . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Request ACK lost . . . . . . . . . . . . . . . . . . . . . 3 2.3. Response lost . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Response ACK lost . . . . . . . . . . . . . . . . . . . . . 4 3. Client perspective . . . . . . . . . . . . . . . . . . . . . . 5 3.1. No request ACK received . . . . . . . . . . . . . . . . . . 5 3.2. Response ACK lost . . . . . . . . . . . . . . . . . . . . . 6 4. Server perspective . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Request ACK lost . . . . . . . . . . . . . . . . . . . . . 7 4.2. Response lost . . . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 6. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Castellani Expires September 27, 2012 [Page 2] Internet-Draft Examples of CoAP Separate Responses March 2012 1. Introduction To be done if interest is shown (TBDIIIS). 2. Taxonomy of cases In the following sections all the possible situations are briefly described. 2.1. Request lost C S | CON MID=0x1234 | | PUT /increment | |-------->X | Figure 1: Example of request lost As shown in Figure 1, this case includes all the situations where the request, including all its retransmissions, has never got through the network up to the server. 2.2. Request ACK lost C S | CON MID=0x1234 | | PUT /increment | |--------------->| | ACK MID=0x1234 | | X<----------| | | Figure 2: Example of request ACK lost As shown in Figure 2, this case includes all the situations where the request has got to the server, but the corresponding ACK has never got through the network up to the client. Castellani Expires September 27, 2012 [Page 3] Internet-Draft Examples of CoAP Separate Responses March 2012 2.3. Response lost C S | CON MID=0x1234 | | PUT /increment | |--------------->| | ACK MID=0x1234 | |<---------------| | | | CON MID=0xfefe | | 2.04 "Done" | | X<----------| Figure 3: Example of response lost As shown in Figure 3, this case includes all the situations where the response and its ACK have not been lost, but the corresponding separate response, including all its retransmissions, has never got through the network up to the client. 2.4. Response ACK lost C S | CON MID=0x1234 | | PUT /increment | |--------------->| | ACK MID=0x1234 | |<---------------| | | | CON MID=0xfefe | | 2.04 "Done" | |<---------------| | ACK MID=0xfefe | |----------->X | Figure 4: Example of response ACK lost As shown in Figure 3, this case includes all the situations where the response, its ACK, and the corresponding separate response have not been lost by the network, but the last ACK sent by the client has been lost. Castellani Expires September 27, 2012 [Page 4] Internet-Draft Examples of CoAP Separate Responses March 2012 3. Client perspective In this section interesting situations incurring to a client implementation are discussed. 3.1. No request ACK received The client cannot distinguish between the first two cases request lost (see Section 2.1) and request ACK lost (see Section 2.1). We call this state C_NO_ACK. C S | CON MID=0x1234 | | PUT /increment | |--------------->| | ACK MID=0x1234 | | X<----------| | | | CON MID=0xfefe | | 2.04 "Done" | |<---------------| Figure 5: Response without ACK Figure 5 shows an example where the client is in the C_NO_ACK state and it receives a CON response in the same session (i.e. matching [loc-host, loc-port, rem-host, rem-port, token]). A realistic but optimistic implementation might think that this response is related to the previous not acked request; a pessimistic but paranoid implementation could decide that the response is NOT related to the previous response. Client implementations supporting only the empty Token (no Token support) are encouraged to randomly select local UDP source port at each new request; this implementation shrewdness smoothly resolves confusion. Always having the Token Option set to a random value realistically resolves any possible confusion in this case, at the obvious cost of its added complexity in the client implementation and network overhead. Castellani Expires September 27, 2012 [Page 5] Internet-Draft Examples of CoAP Separate Responses March 2012 C S | CON MID=0x1234 | | PUT /increment | |--------------->| server processing starts. | ACK MID=0x1234 | | X<----------| | | | CON MID=0x1234 | | PUT /increment | |---------->X | | | | CON MID=0x1234 | | PUT /increment | |--------------->| | ACK MID=0x1234 | | X<----------| | | | | client gives up | | | CON MID=0x1235 | client issues a new request | PUT /decrement | |-------->X | | | | CON MID=0xfefe | server processing ends. | 2.04 "Done" | |<---------------| | ACK MID=0xfefe | |--------------->| | | inconsistency! Figure 6: Naive client Figure 6 shows an incident occurring to a naive client implementation using the empty Token and a static local UDP port. This leads to the indication that a client should in general avoid reusing the same session , i.e., [loc-host, loc-port, rem-host, rem-port, token], even if it has failed. 3.2. Response ACK lost After sending the ACK to the response, a provident client implementation keeps the request session up for some time. This avoids issuing new requests in the same session (i.e. [loc-host, loc- port, rem-host, rem-port, token]), and allows smoothly responding with an empty ACK to response retransmissions received by the server. Castellani Expires September 27, 2012 [Page 6] Internet-Draft Examples of CoAP Separate Responses March 2012 C S | CON MID=0x1234 | | PUT /increment | |--------------->| | ACK MID=0x1234 | |<---------------| | | | CON MID=0xfefe | | 2.04 "Done" | |<---------------| | ACK MID=0xfefe | |---------->X | | | | CON MID=0x1235 | | PUT /decrement | client issues a new request |---------->X | | | | CON MID=0xfefe | server retransmits the response | 2.04 "Done" | |<---------------| | ACK MID=0xfefe | client deduplication did not work |--------------->| Figure 7: Inexperienced client Figure 7 shows an incident occurring to an inexperienced client not having robust deduplication in place and reusing the same session. 4. Server perspective TBDIIIS 4.1. Request ACK lost TBDIIIS 4.2. Response lost The server is said to be in S_NO_ACK when no empty ack to the response is received by the server. Castellani Expires September 27, 2012 [Page 7] Internet-Draft Examples of CoAP Separate Responses March 2012 C S | CON MID=0x1234 | | PUT /increment | |--------------->| | ACK MID=0x1234 | |<---------------| | | | CON MID=0xfefe | | 2.04 "Done" | |<---------------| | ACK MID=0xfefe | |---------->X | | | | CON MID=0xfefe | | 2.04 "Done" | |<---------------| | RST MID=0xfefe | |--------------->| Figure 8: Forgetful client Figure 8 shows the realistic case of a server in state S_NO_ACK, that deals with a client that do not mantains a successful session open after receiving the response. An optimistic server implementation might think that the client has received the response even if it has replied with a RST. C S | CON MID=0x1234 | | PUT /increment | |--------------->| | ACK MID=0x1234 | |<---------------| | | client goes down for reboot | CON MID=0xfefe | | 2.04 "Done" | | X<----------| | | client is up again | CON MID=0xfefe | | 2.04 "Done" | |<---------------| | RST MID=0xfefe | |--------------->| Figure 9: Rebooting client Castellani Expires September 27, 2012 [Page 8] Internet-Draft Examples of CoAP Separate Responses March 2012 However as Figure 9 shows that the very same result might be happen if the server is interacting with a rebooting client. Open issue: Should the server change its behaviour depending on the fact that it received a RST instead of an ACK? (e.g., Should it apply the actual change to the resource only after an ACK to the response has been received?) 5. Acknowledgements Special thanks to Carsten Bormann for substantial contributions on this topic that significantly aided me in compiling this document, to Mattia Gheda for the long discussion had on this topic, and to Jeroen Hoebeke that publicly started discussion on this topic in the CoRE mailing list. Thanks to Zach Shelby, Salvatore Loreto and Guido Moritz for helpful comments and discussions that have shaped the document. 6. Normative References [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-09 (work in progress), March 2012. Author's Address Angelo P. Castellani University of Padova Via Gradenigo 6/B Padova 35131 Italy Email: angelo@castellani.net Castellani Expires September 27, 2012 [Page 9]