Subject: [core] Details for CON notifies RFC7641/RFC7252

From: "Kraus Achim (INST/ECS4)" <[email-masked]>
Date: Mon, 10 Apr 2017 07:49:55 +0000

Hello CORE,

I have some questions according the intended message flow for an observe (RFC7641) which uses CON notifies and the resource is changing while retransmitting the notify and waiting for the ACK. I got aware that (at least one) implementation just modifies the payload in that case leaving the MID an retransmission time from the already pending notify.

Sequence:
CoAP client                                                                                     CoAP server
---------- GET R, CON, MID 1, TOKEN ABCD, Observe 0               ------------>
<-------- 2.05, ACK, MID 1, TOKEN ABCD, Observe 10, "state 1"   -------------
...
<-------- 2.05, CON, MID 65, TOKEN ABCD, Observe 12, "state 2" ------------          (R changed from "state 1" to "state 2")
<-------- 2.05, CON, MID 65, TOKEN ABCD, Observe 12, "state 2" ------------          (retransmission, because ACK missing)
...
<-------- 2.05, CON, MID 65, TOKEN ABCD, Observe 14, "state 3" ------------          (R changed from "state 2" to "state 3")  
----------                                   ACK, MID 65                                     ------------>

So:
Is it intended to (re-)use a MID with a modified message? (I personally would say, this is a NO GO!).
Should the retransmission timing/counter from the first notify be continued?
Should this continuing also prevent the second change to be send delayed with the next retransmission? 
Or should the second change simply wait until the first timeout all retransmission?

There may be even different answers/intended usage, depending on the usage of the CON notify:
If it's used the test the liveliness of the observe or
If it's used to ensure (in my opinion a pseudo) safe state transfer  
 
My personal favorite would be, just cancel the first CON notify and start a new one with the updated payload
immediately (new MID, new retransmission setup with reset counter and timeout).

Mit freundlichen Grüßen / Best regards

Achim Kraus

Bosch Software Innovations GmbH
Communications (INST/ECS4)
Stuttgarter Straße 130
71332 Waiblingen
GERMANY
www.bosch-si.de
www.blog.bosch-si.com 

Tel. +49 711 811-58139
[email-masked]

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 10 Apr 2017 10:11:10 +0200

Hi Achim,

these questions are very good material for draft-ietf-lwig-coap, the authors of which I CC.

The main reference here is Section 4.5.2 of RFC 7641, especially the guidance under "supersede an outstanding transmission”.

> Is it intended to (re-)use a MID with a modified message? (I personally would say, this is a NO GO!).

If the client already acknowledged the notification, but that ack got lost, the notification with a changed payload might simply be ACKed by the client in the deduplication mechanism.  Also, we need a new MID to be sure that the changed payload actually is being ACKed.

RFC 7641 does not leave this open to speculation:

   4.  The new notification is transmitted with a new Message ID […]

> Should the retransmission timing/counter from the first notify be continued?

It MAY be, but there is no SHOULD.

> Or should the second change simply wait until the first timeout all retransmission?

If all retransmissions time out, the server does not know whether the client is still there.  Depending on how robust interest entries are maintained, the server may give up completely on this interest (i.e., cancel the observation, see 4.5), or it may retry a few times later (robustness features are not specified in RFC 7641).

> immediately (new MID, new retransmission setup with reset counter and timeout).

The problem with this is that this circumvents congestion control:

Imagine a server that has a new value every 0.1 s.  If the old transmission is canceled each time there is a new value, the server now sends packets at 10 Hz without any congestion control.  Not good.  So the server has to slow down on lack of ACKs: Either by completing the old transfer (with stale data), or by using the “superseding” mechanism of Section 4.5.2.

Grüße, Carsten

---

From: "Kraus Achim (INST/ECS4)" <[email-masked]>
Date: Mon, 10 Apr 2017 11:05:32 +0000

Hi Carsten,

Thanks for your fast answer!

Your perfectly right, that RFC7641, 4.5.2 specifies the behavior for the scenario.  

And good to know, that draft-ietf-lwig-coap is alive, because when I looked at it
on January it seems to me to be no longer alive.

Achim Kraus

-----Ursprüngliche Nachricht-----
Von: Carsten Bormann [mailto:[email-masked]] 
Gesendet: Montag, 10. April 2017 10:11
An: Kraus Achim (INST/ECS4) <[email-masked]>
Cc: [email-masked]; [email-masked]
Betreff: Re: [core] Details for CON notifies RFC7641/RFC7252

Hi Achim,

> My personal favorite would be, just cancel the first CON notify and 
> start a new one with the updated payload immediately (new MID, new retransmission setup with reset counter and timeout).

Grüße, Carsten