One document matched: draft-castellani-lwig-coap-separate-responses-00.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.ietf-core-coap SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-core-coap-09.xml">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<?rfc strict="no"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc ipr="trust200902"
docName="draft-castellani-lwig-coap-separate-responses-00" category='info'>
<front>
<title abbrev="Examples of CoAP Separate Responses">
Learning CoAP separate responses by examples
</title>
<author initials="A.P." surname="Castellani" fullname="Angelo P. Castellani">
<organization>University of Padova</organization>
<address>
<postal>
<street>Via Gradenigo 6/B</street>
<code>35131</code>
<city>Padova</city>
<country>Italy</country>
</postal>
<email>angelo@castellani.net</email>
</address>
</author>
<date year="2012" />
<area>APP</area>
<workgroup>LWIG Working Group</workgroup>
<keyword>CoAP</keyword>
<keyword>Separate responses</keyword>
<keyword>Examples</keyword>
<abstract>
<t>This draft aims at providing interesting examples of CoAP separate responses
that are useful to aid CoAP implementers on understanding possible rare situation incurring.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>To be done if interest is shown (TBDIIIS).</t>
</section>
<section title="Taxonomy of cases">
<t>In the following sections all the possible situations are briefly described.</t>
<section title="Request lost" anchor="request-lost">
<figure title="Example of request lost" anchor="fig-request-lost"><artwork>
<![CDATA[
C S
| CON MID=0x1234 |
| PUT /increment |
|-------->X |
]]>
</artwork></figure>
<t>As shown in <xref target="fig-request-lost"/>,
this case includes all the situations where the request, including all its retransmissions,
has never got through the network up to the server.</t>
</section>
<section title="Request ACK lost" anchor="request-ack-lost">
<figure title="Example of request ACK lost" anchor="fig-request-ack-lost"><artwork>
<![CDATA[
C S
| CON MID=0x1234 |
| PUT /increment |
|--------------->|
| ACK MID=0x1234 |
| X<----------|
| |
]]>
</artwork></figure>
<t>As shown in <xref target="fig-request-ack-lost"/>,
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.</t>
</section>
<section title="Response lost" anchor="response-lost">
<figure title="Example of response lost" anchor="fig-response-lost"><artwork>
<![CDATA[
C S
| CON MID=0x1234 |
| PUT /increment |
|--------------->|
| ACK MID=0x1234 |
|<---------------|
| |
| CON MID=0xfefe |
| 2.04 "Done" |
| X<----------|
]]>
</artwork></figure>
<t>As shown in <xref target="fig-response-lost"/>,
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.</t>
</section>
<section title="Response ACK lost" anchor="response-ack-lost">
<figure title="Example of response ACK lost" anchor="fig-response-ack-lost"><artwork>
<![CDATA[
C S
| CON MID=0x1234 |
| PUT /increment |
|--------------->|
| ACK MID=0x1234 |
|<---------------|
| |
| CON MID=0xfefe |
| 2.04 "Done" |
|<---------------|
| ACK MID=0xfefe |
|----------->X |
]]>
</artwork></figure>
<t>As shown in <xref target="fig-response-lost"/>,
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.</t>
</section>
</section>
<section title="Client perspective" anchor="client">
<t>In this section interesting situations incurring to a client implementation are discussed.</t>
<section title="No request ACK received" anchor="client-no-ack">
<t>The client cannot distinguish between the first two cases
request lost (see <xref target="request-lost"/>) and request ACK lost (see <xref target="request-lost"/>).
We call this state C_NO_ACK.</t>
<figure title="Response without ACK" anchor="fig-no-ack-response"><artwork>
<![CDATA[
C S
| CON MID=0x1234 |
| PUT /increment |
|--------------->|
| ACK MID=0x1234 |
| X<----------|
| |
| CON MID=0xfefe |
| 2.04 "Done" |
|<---------------|
]]>
</artwork></figure>
<t><xref target="fig-no-ack-response"/> 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.</t>
<t>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.</t>
<t>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.</t>
<figure title="Naive client" anchor="fig-naive-client"><artwork>
<![CDATA[
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!
]]>
</artwork></figure>
<t><xref target="fig-naive-client"/> 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.</t>
</section>
<section title="Response ACK lost" anchor="client-res-ack-lost" >
<t>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.</t>
<figure title="Inexperienced client" anchor="fig-inexperienced-client"><artwork>
<![CDATA[
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
|--------------->|
]]>
</artwork></figure>
<t><xref target="fig-inexperienced-client"/> shows an incident occurring to an inexperienced client
not having robust deduplication in place and reusing the same session.</t>
</section>
</section>
<section title="Server perspective" anchor="server">
<t>TBDIIIS</t>
<section title="Request ACK lost">
<t>TBDIIIS</t>
</section>
<section title="Response lost">
<t>The server is said to be in S_NO_ACK when no empty ack to the response is received by the server.</t>
<figure title="Forgetful client" anchor="fig-forgetful-client"><artwork>
<![CDATA[
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 |
|--------------->|
]]>
</artwork></figure>
<t><xref target="fig-forgetful-client"/> 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.</t>
<figure title="Rebooting client" anchor="fig-rebooting-client"><artwork>
<![CDATA[
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 |
|--------------->|
]]>
</artwork></figure>
<t>However as <xref target="fig-rebooting-client"/> shows that the very same result might be happen
if the server is interacting with a rebooting client.</t>
<t>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?)</t>
</section>
</section>
<section title="Acknowledgements">
<t>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.</t>
<t>Thanks to
Zach Shelby,
Salvatore Loreto and
Guido Moritz
for helpful comments and discussions that have shaped the document.</t>
</section>
</middle>
<back>
<references title="Normative References">
&I-D.ietf-core-coap;
</references>
</back>
</rfc>
<!-- Change log
-->
<!-- LocalWords: xref CDATA exploders BUA -->
| PAFTECH AB 2003-2026 | 2026-04-23 20:58:29 |