Subject: [Lwip] Fwd: [core] draft-ietf-core-coap-09: Separate response in a lossy context

From: Zhen Cao <[email-masked]>
Date: Mon, 26 Mar 2012 19:44:49 +0200

Should definitely be of interest to implementers here.

---------- Forwarded message ----------
From: Jeroen Hoebeke <[email-masked]>
Date: Mon, Mar 26, 2012 at 5:19 PM
Subject: [core] draft-ietf-core-coap-09: Separate response in a lossy context
To: core WG <[email-masked]>

Dear working group,

During the plug test event, we noticed different behavior of
implementations in case of separated responses in a lossy context.

Case 1:
- client sends CON request
- ACK from server is lost
- separate CON response from server to client
- ACK from client to server

Some implementations do not consider the CON response as an implicit
acknowledgement and retransmit the CON request, causing unnecessary
traffic. In section 4.1, the draft says:
>
> In particular, a CoAP request message may have elicited a
>    separate response, in which case it is clear to the requester that
>    only the ACK was lost and a retransmission of the request would serve
>    no purpose.

This is only an implementation note. It would be better to state
explicitly in section 4.1 of the draft: "The reception of a separate
confirmable response before the acknowledgement should be considered
as an implicit acknowledgement and should not result in a
retransmission of the request in case the acknowledgment never
arrives."

Case 2:
- client sends CON request
- server sends ACK
- server sends separate CON response
- ACK from client to server is lost
- server retransmits the CON response
In several implementations, the reception of the ACK results in the
removal of the context of the transaction (which makes sense for
constrained devices). When the server retransmits the response, this
results in a RST message.

It would be useful to describe this behavior in section 4.1 (or
section 4.4.4 as one of the cases where a RST is sent). For a CON
request for which the ACK is lost, this behavior is well explained in
section 4.1, but for the CON response for which the ACK is lost this
is missing.

"The reception of a retransmitted confirmable response due to the loss
of the client's acknowledgment, may result in RST message in case the
client removed the state information after sending the
acknowledgment."

Kind regards,
Jeroen Hoebeke

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

-- 
Best regards,
Zhen

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Tue, 27 Mar 2012 11:32:48 +0200

On Tue, Mar 27, 2012 at 00:59, Thomas Fossati <[email-masked]> wrote:

> http://koanlogic.com/coap/evcoap-server-fsm.pdf
> http://koanlogic.com/coap/evcoap-client-fsm.pdf

Nice drawing Thomas.

I think that your graph is more focused on the overall server/client
software implementation, and I found it quite complex to read from a
protocol perspective (are some states even missing?).

Following the suggestion of Guido, I tried to sketch the FSM of CoAP itself
from a protocol perspective point-of-view, mainly to better understand all
the possible transitions.

If you mind to have a look, you can find it here:
http://www.dei.unipd.it/~castellani/coap-fsm.pdf
(it is really a draft version right now, please be patient if you find any
error)

Best,
Angelo

p.s.: I still have to add the RST messages to the graph, I will update this
later.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 27 Mar 2012 13:31:38 +0200

> http://www.dei.unipd.it/~castellani/coap-fsm.pdf

Can we try to separate the message and request/response layers?

Grüße, Carsten

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Tue, 27 Mar 2012 13:53:54 +0200

> Can we try to separate the message and request/response layers?

Having the Token Option in the request/response layer leads to a problem in
the separation.

In this state machine graph I made the assumption that proper session
matching is applied before applying state transitions. In my point of view
"proper session matching" means checking (loc-host, loc-port, rem-host,
rem-port, token).

Legenda: "loc: Local", "rem: Remote", "host: IP Host", "port: UDP Port",
"token: CoAP Token Option"

If I remove the Token Option from the session matching condition (i.e., I
check [loc-host, loc-port, rem-host, rem-port]), I can't devise any real
state since I can still receive any message in any state, and transition to
any other state depending upon the Token contained in it... Suggestions?

Best,
Angelo

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Wed, 28 Mar 2012 16:08:06 +0200

> Can we try to separate the message and request/response layers?

I have built a FSM with the message-layer splitted from the
request/response-layer. I will validate this by implementation.

If you want to have a look at that you can find it here:
http://www.dei.unipd.it/~castellani/coap_m_fsm.pdf
http://www.dei.unipd.it/~castellani/coap_rr_fsm.pdf

Comments are welcome.

(it is a draft drawing, please be patient).

Best,
Angelo

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 28 Mar 2012 17:51:51 +0200

> http://www.dei.unipd.it/~castellani/coap_m_fsm.pdf

I like that much better.

The RETX ACK is missing its reason (i.e., having got another copy of the CON).

It would also probably be useful to indicate that this is a state per MID, and that MIDs attach to the *sender* of the NON/CON.

TX-CON allocates a MID.

NONs received get dedupped, too (except see below), and their MIDs time out the same way.

In my implementation there is also a reply from the RR layer upon a received CON or NON that the RR layer (or its client) didn't care about duplicate detection ("stateless").  This MID then goes right back to closed.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 28 Mar 2012 17:59:06 +0200

> http://www.dei.unipd.it/~castellani/coap_rr_fsm.pdf

Again, much better.

The states are per token.
Note that the client (the one who sent the request) selects the token, and the token again attaches to the endpoint pair.

Block (with M=1 responses) and observe create somewhat more complex state charts.

A somewhat novel event in my implementation is "active token was reused":

When a client starts using the same token for a request that the server thought still was active (e.g., for an observation relationship or for a pending response), this activity is effectively canceled.

Grüße, Carsten