Subject: Re: [core] Multicast response suppression, random back-off (ticket #177)

From: "Dijk, Esko" <[email-masked]>
Date: Fri, 6 Jan 2012 12:28:27 +0000

Hello Carsten, Salvatore, Kepeng,

Some comments below. I'll use name the proposed name "Patience" from here on.

> I was trying to argue that the two time frames (client patience, server dithering) are exactly the same ones:
> In the multicast case, the server would try to dither within the exactly the time frame that the requester is
> prepared to wait. So there is never a good reason to indicate another time frame.

In our multicast lighting use case, the time values for 'client patience' and 'server dithering' are typically different. For example, a client requests "dithering" between 0-300 ms when doing a request to a group of lights. But if a couple of lights in the group are slower in responding (say, up to 1 or 2 seconds) this is still ok. No need for a server to cancel the operation because some internal delay >T occurred.

Phrased in terms of a "Patience" Option with a value T, I see three possible types of 'patience' this Option could mean:

#1 Client Patience: client indicates own patience; requester prepared to wait for at most time T. After T, responses are not of interest anymore.
#2 Server Patience: client asks server to be patient; server should wait a time between 0 and T, *if possible*, before responding. Responses generated later than T are still of interest to the client.
#3 Both Client and Server Patience: the union of above #1 and #2. After T, responses are not of interest anymore.

[ #2/#3 seem only relevant when applied to multicast requests? #1 is relevant for both unicast/multicast requests.]

Semantics #3, for multicast, coincides with Carsten's proposal. In my view #2 is easiest to specify in CoAP because we don't have to consider what to do with cancelling POST/PUT requests, which 4.xx/5.xx errors to return when, etc., problems mentioned in this mail thread. Plus it fits well to the multicast lighting use case. And, it addresses the multicast congestion issues i.e. ticket #177 with minimal added complexity.

My proposal: why not define a separate elective Option "Backoff" or "(Server) Patience" or <other name>, with semantics #2, that SHOULD be used only in multicast CoAP requests ?

regards,
Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Wednesday 21 December 2011 19:59
To: Salvatore Loreto
Cc: [email-masked]
Subject: Re: [core] Multicast response suppression, random back-off (ticket #177)

>>> About the semantics: There is a clearly different semantics between "response is most useful before time T" and "if possible please delay your response by a random time within [0,T]". The first is an application concern, while the second is more to 'engineer' the network traffic patterns to an acceptable behaviour i.e. related to the CoAP messaging 'sublayer'. Under the first semantics there's no reason to delay anything while under the second semantics this is the key point.
>> While this is true, the difference is in the unicast (reply now) vs. multicast (reply with a dithered delay) semantics, not in the semantics of the option that is giving the desired time frame.
>
>
> just for the sake to try to understand better the scenario and the semantic:
> could the "response is most useful before time T" semantic be somehow useful also for multicast request?

I was trying to argue that the two time frames (client patience, server dithering) are exactly the same ones:
In the multicast case, the server would try to dither within the exactly the time frame that the requester is prepared to wait.
So there is never a good reason to indicate another time frame.
(Note that, in all cases, the time is extended by network latency.  There also should be some exhortation that a retransmitting sender *should* adjust the time if that is indeed what the sender wants.)

> most likely the server can not figure it out in advance whether or not it will be able to honor the request-timeout
> it will only discover that once it has already started to elaborate the POST/PUT request
> however both POST and PUT request are not save, POST is not idempotent while PUT is idempotent.
>
> so we have to think carefully how to apply the Request-Timeout (or whatever this option will finally named) for POST/PUT methods

Right.
But I'm pretty sure in the end what we write there will amount to "the server should do the right thing"...
The semantics are just too different in different applications and kinds of resources.

Grüße, Carsten

PS.: Maybe "Patience" is indeed the right name for that option...

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

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Likepeng <[email-masked]>
Date: Sat, 07 Jan 2012 00:20:16 +0000

> My proposal: why not define a separate elective Option "Backoff" or "(Server) Patience" or <other name>, with semantics #2, that SHOULD be used only in multicast CoAP requests ?

Another alternative is to allocate one bit to differentiate whether it is a "client patience" or "server patience". This will reduce the range of the time, but maybe we can allocate two bytes for the option, instead of one byte.

I am fine with either way.

Thanks,
Kind Regards
Kepeng
-----邮件原件-----
发件人: Dijk, Esko [mailto:[email-masked]] 
发送时间: 2012年1月6日 20:28
收件人: Carsten Bormann; Salvatore Loreto; Likepeng
抄送: [email-masked]
主题: RE: [core] Multicast response suppression, random back-off (ticket #177)

regards,
Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Wednesday 21 December 2011 19:59
To: Salvatore Loreto
Cc: [email-masked]
Subject: Re: [core] Multicast response suppression, random back-off (ticket #177)

Right.

Grüße, Carsten