[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/