Subject: Re: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-00.txt

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 2 Sep 2013 09:28:20 +0000

Hi all,

some FYI input below, since part of this discussion is already documented in I-Ds.

> I think it is especially useful in combination with multicast, e.g. when a single client sends a POST to a group of actuators, which just need to act, not to respond. However, according to CoAP-18, the ?
> server now is also allowed to suppress a response to a multicast request when it deems that appropriate. But this would allow the client to explicitly indicate its disinterest in the responses.
Agree, see http://tools.ietf.org/html/draft-ietf-core-groupcomm-12#section-3.7 for more detailed analysis for the multicast use case!
This section also shows that in fact more granularity in response suppression would be useful, not just "response: yes/no". For example: suppress 2.xx response but not 4.xx/5.xx. Note that the current groupcomm solution to solve this is to have the server's behaviour for multicast responses configured at a per-resource level. Having a granular response suppression option would be nice to avoid such 'hardcoding'.

> the option has the advantage that it can be elective. ... Using a separate UPOST/UPUT method would miss that advantage.
Yes, agree.

> BTW, the use case in the draft assumes the sensor to in the vehicle to be CoAP client, and the central tracker the CoAP server. This could be done differently, i.e. let the vehicle sensor be the CoAP
> server and the central tracker be the CoAP client. Then this particular use case can indeed be achieved with observe.
Agree again; note that in a typical design for sleepy, battery-powered sensors the sensors would indeed always act as the CoAP clients (initiator of the communication). (For background see http://tools.ietf.org/html/draft-dijk-core-sleepy-solutions-01#section-3.3.1 and its following sections, or the Mirror Server I-D.)

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bert Greevenbosch
Sent: Saturday, August 31, 2013 08:29
To: Carsten Bormann; Abhijan Bhattacharyya
Cc: [email-masked]
Subject: Re: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-00.txt

Hi Abhijan, Carsten, all,

Interesting draft indeed. The server was already allowed to send unidirectional messages through NON-responses, this draft would allow unidirectional messages in the other direction too.

I think it is especially useful in combination with multicast, e.g. when a single client sends a POST to a group of actuators, which just need to act, not to respond. However, according to CoAP-18, the server now is also allowed to suppress a response to a multicast request when it deems that appropriate. But this would allow the client to explicitly indicate its disinterest in the responses.

Unidirectional requests can also save energy for transmission on the server side. I could even imagine very simple actuators that only have a receiving module. Similarly to clients with only a sending module. Now this is already possible - the client doesn't need to process a NON-response and can choose to not even receive it - but, as already mentioned, this would allow the client to explicitly indicate its disinterest in the response.

Concerning the option vs. separate suite issue, the option has the advantage that it can be elective. In this case, understanding devices will act according to the option, but legacy devices will still be able to use the message although they might send the response. Using a separate UPOST/UPUT method would miss that advantage.

BTW, the use case in the draft assumes the sensor to in the vehicle to be CoAP client, and the central tracker the CoAP server. This could be done differently, i.e. let the vehicle sensor be the CoAP server and the central tracker be the CoAP client. Then this particular use case can indeed be achieved with observe.

Best regards,
Bert

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Carsten Bormann
> Sent: 2013年8月30日 19:06
> To: Abhijan Bhattacharyya
> Cc: [email-masked]
> Subject: Re: [core] Fw: New Version Notification for
> draft-tcs-coap-no- response-option-00.txt
>
> Hi Abhijan,
>
> thank you for submitting this draft.
>
> The idea to handle unidirectional requests has come up in the past; we
> just didn't seem to have the energy to work on it.
>
> Questions that I remember coming up include:
>
> -- Is this best handled as an option (that would apply to multiple
> requests) or as a separate suite of request methods (say, UPUT, UPOST)?
> Clearly, unidirectional doesn't make sense for GET :-)
> -- What is the boundary between the use cases best handled by observe
> and those best handled by unidirectional requests?
> -- What are the congestion control implications of unidirectional
> requests?  I think we now understand how to handle this with observe;
> the solutions may be transferrable.
>
> So, what applications of unidirectional requests do others have in mind?
> Other things we need to think about?
>
> Grüße, Carsten
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
_______________________________________________
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.