idnits 2.17.1 draft-castellani-lwig-coap-separate-responses-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 26, 2012) is 4413 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-core-coap' is defined on line 342, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-09 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LWIG Working Group A. Castellani 3 Internet-Draft University of Padova 4 Intended status: Informational March 26, 2012 5 Expires: September 27, 2012 7 Learning CoAP separate responses by examples 8 draft-castellani-lwig-coap-separate-responses-00 10 Abstract 12 This draft aims at providing interesting examples of CoAP separate 13 responses that are useful to aid CoAP implementers on understanding 14 possible rare situation incurring. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 27, 2012. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Taxonomy of cases . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Request lost . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.2. Request ACK lost . . . . . . . . . . . . . . . . . . . . . 3 54 2.3. Response lost . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.4. Response ACK lost . . . . . . . . . . . . . . . . . . . . . 4 56 3. Client perspective . . . . . . . . . . . . . . . . . . . . . . 5 57 3.1. No request ACK received . . . . . . . . . . . . . . . . . . 5 58 3.2. Response ACK lost . . . . . . . . . . . . . . . . . . . . . 6 59 4. Server perspective . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. Request ACK lost . . . . . . . . . . . . . . . . . . . . . 7 61 4.2. Response lost . . . . . . . . . . . . . . . . . . . . . . . 7 62 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 63 6. Normative References . . . . . . . . . . . . . . . . . . . . . 9 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 1. Introduction 68 To be done if interest is shown (TBDIIIS). 70 2. Taxonomy of cases 72 In the following sections all the possible situations are briefly 73 described. 75 2.1. Request lost 77 C S 78 | CON MID=0x1234 | 79 | PUT /increment | 80 |-------->X | 82 Figure 1: Example of request lost 84 As shown in Figure 1, this case includes all the situations where the 85 request, including all its retransmissions, has never got through the 86 network up to the server. 88 2.2. Request ACK lost 90 C S 91 | CON MID=0x1234 | 92 | PUT /increment | 93 |--------------->| 94 | ACK MID=0x1234 | 95 | X<----------| 96 | | 98 Figure 2: Example of request ACK lost 100 As shown in Figure 2, this case includes all the situations where the 101 request has got to the server, but the corresponding ACK has never 102 got through the network up to the client. 104 2.3. Response lost 106 C S 107 | CON MID=0x1234 | 108 | PUT /increment | 109 |--------------->| 110 | ACK MID=0x1234 | 111 |<---------------| 112 | | 113 | CON MID=0xfefe | 114 | 2.04 "Done" | 115 | X<----------| 117 Figure 3: Example of response lost 119 As shown in Figure 3, this case includes all the situations where the 120 response and its ACK have not been lost, but the corresponding 121 separate response, including all its retransmissions, has never got 122 through the network up to the client. 124 2.4. Response ACK lost 126 C S 127 | CON MID=0x1234 | 128 | PUT /increment | 129 |--------------->| 130 | ACK MID=0x1234 | 131 |<---------------| 132 | | 133 | CON MID=0xfefe | 134 | 2.04 "Done" | 135 |<---------------| 136 | ACK MID=0xfefe | 137 |----------->X | 139 Figure 4: Example of response ACK lost 141 As shown in Figure 3, this case includes all the situations where the 142 response, its ACK, and the corresponding separate response have not 143 been lost by the network, but the last ACK sent by the client has 144 been lost. 146 3. Client perspective 148 In this section interesting situations incurring to a client 149 implementation are discussed. 151 3.1. No request ACK received 153 The client cannot distinguish between the first two cases request 154 lost (see Section 2.1) and request ACK lost (see Section 2.1). We 155 call this state C_NO_ACK. 157 C S 158 | CON MID=0x1234 | 159 | PUT /increment | 160 |--------------->| 161 | ACK MID=0x1234 | 162 | X<----------| 163 | | 164 | CON MID=0xfefe | 165 | 2.04 "Done" | 166 |<---------------| 168 Figure 5: Response without ACK 170 Figure 5 shows an example where the client is in the C_NO_ACK state 171 and it receives a CON response in the same session (i.e. matching 172 [loc-host, loc-port, rem-host, rem-port, token]). A realistic but 173 optimistic implementation might think that this response is related 174 to the previous not acked request; a pessimistic but paranoid 175 implementation could decide that the response is NOT related to the 176 previous response. 178 Client implementations supporting only the empty Token (no Token 179 support) are encouraged to randomly select local UDP source port at 180 each new request; this implementation shrewdness smoothly resolves 181 confusion. 183 Always having the Token Option set to a random value realistically 184 resolves any possible confusion in this case, at the obvious cost of 185 its added complexity in the client implementation and network 186 overhead. 188 C S 189 | CON MID=0x1234 | 190 | PUT /increment | 191 |--------------->| server processing starts. 192 | ACK MID=0x1234 | 193 | X<----------| 194 | | 195 | CON MID=0x1234 | 196 | PUT /increment | 197 |---------->X | 198 | | 199 | CON MID=0x1234 | 200 | PUT /increment | 201 |--------------->| 202 | ACK MID=0x1234 | 203 | X<----------| 204 | | 205 | | client gives up 206 | | 207 | CON MID=0x1235 | client issues a new request 208 | PUT /decrement | 209 |-------->X | 210 | | 211 | CON MID=0xfefe | server processing ends. 212 | 2.04 "Done" | 213 |<---------------| 214 | ACK MID=0xfefe | 215 |--------------->| 216 | | inconsistency! 218 Figure 6: Naive client 220 Figure 6 shows an incident occurring to a naive client implementation 221 using the empty Token and a static local UDP port. This leads to the 222 indication that a client should in general avoid reusing the same 223 session , i.e., [loc-host, loc-port, rem-host, rem-port, token], even 224 if it has failed. 226 3.2. Response ACK lost 228 After sending the ACK to the response, a provident client 229 implementation keeps the request session up for some time. This 230 avoids issuing new requests in the same session (i.e. [loc-host, loc- 231 port, rem-host, rem-port, token]), and allows smoothly responding 232 with an empty ACK to response retransmissions received by the server. 234 C S 235 | CON MID=0x1234 | 236 | PUT /increment | 237 |--------------->| 238 | ACK MID=0x1234 | 239 |<---------------| 240 | | 241 | CON MID=0xfefe | 242 | 2.04 "Done" | 243 |<---------------| 244 | ACK MID=0xfefe | 245 |---------->X | 246 | | 247 | CON MID=0x1235 | 248 | PUT /decrement | client issues a new request 249 |---------->X | 250 | | 251 | CON MID=0xfefe | server retransmits the response 252 | 2.04 "Done" | 253 |<---------------| 254 | ACK MID=0xfefe | client deduplication did not work 255 |--------------->| 257 Figure 7: Inexperienced client 259 Figure 7 shows an incident occurring to an inexperienced client not 260 having robust deduplication in place and reusing the same session. 262 4. Server perspective 264 TBDIIIS 266 4.1. Request ACK lost 268 TBDIIIS 270 4.2. Response lost 272 The server is said to be in S_NO_ACK when no empty ack to the 273 response is received by the server. 275 C S 276 | CON MID=0x1234 | 277 | PUT /increment | 278 |--------------->| 279 | ACK MID=0x1234 | 280 |<---------------| 281 | | 282 | CON MID=0xfefe | 283 | 2.04 "Done" | 284 |<---------------| 285 | ACK MID=0xfefe | 286 |---------->X | 287 | | 288 | CON MID=0xfefe | 289 | 2.04 "Done" | 290 |<---------------| 291 | RST MID=0xfefe | 292 |--------------->| 294 Figure 8: Forgetful client 296 Figure 8 shows the realistic case of a server in state S_NO_ACK, that 297 deals with a client that do not mantains a successful session open 298 after receiving the response. An optimistic server implementation 299 might think that the client has received the response even if it has 300 replied with a RST. 302 C S 303 | CON MID=0x1234 | 304 | PUT /increment | 305 |--------------->| 306 | ACK MID=0x1234 | 307 |<---------------| 308 | | client goes down for reboot 309 | CON MID=0xfefe | 310 | 2.04 "Done" | 311 | X<----------| 312 | | client is up again 313 | CON MID=0xfefe | 314 | 2.04 "Done" | 315 |<---------------| 316 | RST MID=0xfefe | 317 |--------------->| 319 Figure 9: Rebooting client 321 However as Figure 9 shows that the very same result might be happen 322 if the server is interacting with a rebooting client. 324 Open issue: Should the server change its behaviour depending on the 325 fact that it received a RST instead of an ACK? (e.g., Should it apply 326 the actual change to the resource only after an ACK to the response 327 has been received?) 329 5. Acknowledgements 331 Special thanks to Carsten Bormann for substantial contributions on 332 this topic that significantly aided me in compiling this document, to 333 Mattia Gheda for the long discussion had on this topic, and to Jeroen 334 Hoebeke that publicly started discussion on this topic in the CoRE 335 mailing list. 337 Thanks to Zach Shelby, Salvatore Loreto and Guido Moritz for helpful 338 comments and discussions that have shaped the document. 340 6. Normative References 342 [I-D.ietf-core-coap] 343 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 344 "Constrained Application Protocol (CoAP)", 345 draft-ietf-core-coap-09 (work in progress), March 2012. 347 Author's Address 349 Angelo P. Castellani 350 University of Padova 351 Via Gradenigo 6/B 352 Padova 35131 353 Italy 355 Email: angelo@castellani.net