Subject: [core] CoAP No-Response: use with NON only?

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 27 Jan 2015 17:04:14 +0000

Hello Abhijan,

The use of the option with NON only is not made crystal clear yet: "primarily intended to be used with non-confirmable update requests (e.g., PUT) and should have no effect if used with a CON  request." leaves open an implementation where it does work with CON and leaves clients free to use it with CON. However Section 1 states "At present this option will have no effect if used with confirmable (CON) mode." Which is saying it musn't work with CON on the server side.

I would like to question this NON-only behavior. Why not make it work for CON as well? Use case: my client is frequently POSTing  to a specific resource. However the resource returns a big data blob in the response always, which the client is not interested in. Client would like to use No-Response to stop receiving the big data blob all the time.
If CON is unwanted for certain reasons perhaps it should be explained in the I-D? One possible reason could be that supporting the option for CON is more implementation effort in a CoAP server. Maybe I just missed the part where this is explained.

And a minor point; Table in Section 6 lists "Section 4", which should be Section 2.

Esko

From: core [mailto:[email-masked]] On Behalf Of Abhijan Bhattacharyya
Sent: Wednesday, January 21, 2015 13:35
To: [email-masked]
Subject: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-08.txt

Hi all,
A modified version of the No-Response draft has been submitted. This draft has so far addressed all the technical comments received during the past meetings and mailing list discussions. We would urge the CoRE members to do a review of the draft and share their comments. Also, would request people to implement this option.

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: [email-masked]<mailto:[email-masked]>
Website: http://www.tcs.com<http://www.tcs.com/>
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________
----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 01/21/2015 05:58 PM -----

From:        [email-masked]<mailto:[email-masked]>
To:        Soma Bandyopadhyay <[email-masked]<mailto:[email-masked]>>, "Abhijan Bhattacharyya" <[email-masked]<mailto:[email-masked]>>, "Arpan Pal" <[email-masked]<mailto:[email-masked]>>, Arpan Pal <[email-masked]<mailto:[email-masked]>>, "Soma Bandyopadhyay" <[email-masked]<mailto:[email-masked]>>, Abhijan Bhattacharyya <[email-masked]<mailto:[email-masked]>>
Date:        01/21/2015 05:57 PM
Subject:        New Version Notification for draft-tcs-coap-no-response-option-08.txt
________________________________

A new version of I-D, draft-tcs-coap-no-response-option-08.txt
has been successfully submitted by Abhijan Bhattacharyya and posted to the
IETF repository.

Name:                                  draft-tcs-coap-no-response-option
Revision:                 08
Title:                                  CoAP option for no server-response
Document date:                 2015-01-21
Group:                                  Individual Submission
Pages:                                  17
URL:            http://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-08.txt
Status:         https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/
Htmlized:       http://tools.ietf.org/html/draft-tcs-coap-no-response-option-08
Diff:           http://www.ietf.org/rfcdiff?url2=draft-tcs-coap-no-response-option-08

Abstract:
  There can be typical M2M scenarios where responses from server
  against request from client might be considered redundant. This kind
  of open-loop exchange (with no reverse path from the server to the
  client) may be typically desired to minimize resource consumption in
  constrained systems while simultaneously updating a bulk of
  resources or updating a resource with a very high frequency. CoAP
  already provides a non-confirmable (NON) mode of exchange where the
  server end-point does not respond with ACK. However, the server end-
  point responds back with a status code indicating "the result of the
  attempt to understand and satisfy the request".

  This draft introduces a header option for CoAP called 'No-Response'.
  The option explicitly tells the server to suppress responses about
  the state of the resource against the request from the client. This
  option also provides granular control by allowing suppression of a
  typical class or a combination of classes of responses. This option
  may be effective for both unicast and multicast requests. This draft
  discusses few exemplary applications which might benefit from this
  option.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

________________________________
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: Abhijan Bhattacharyya <[email-masked]>
Date: Wed, 28 Jan 2015 09:50:51 +0530

Hi Esko,

Thanks for raising this interesting issue.

>The use of the option with NON only is not made crystal clear yet:

>&#8220;primarily intended to be used with non-confirmable update requests

>(e.g., PUT) and should have no effect

> if used with a CON  request.&#8221;  ..... &#8220;At present this option will have no effect

>if used with confirmable (CON) mode.&#8221; 

Well, as you can see, the language is kept deliberately 'soft' so that the door is not completely closed for CON. :)

But, do you think these two statements are contradictory? What we wanted to mean is that use of No-response with CON should not report an error but should be handled transparently.

>If CON is unwanted for certain reasons perhaps it should be explained

>in the I-D?

The reason why CON is not kept now is that, CON anyway will have a feedback path from server to client even if we suppress the response. So the path has to be through the messaging layer in the form of an ACK. The use cases we had at hand were only demanding small feedbacks about status of the request. But they were demanding network resources frequently and/or concurrently in large volume (as in case of multicasting light switches to ON/OFF). In these cases responses are mostly piggybacked with ACK for CON requests. Now, if you look into the response payload structure for piggy-backed responses for such update scenarios, No-Response is not going to save us any bandwidth. The ACK is anyway coming back.

Now, we did put a hint about a situation that might be relevant for CON in page 4 of he very first version of the draft (https://tools.ietf.org/html/draft-tcs-coap-no-response-option-00 ):

"[TBD1: Probably this option may be useful for CON mode as well in

   case of separate responses. There may be certain scenarios where the

   ACK is enough to satisfy the client application and one extra flight 

   due to the separate status response may be avoided.]"

We removed this text in subsequent versions as it did not seem to be appealing to use this option with CON at that time for lack of driving use cases.

Please share your further views on this and also, it will be good if you could elaborate a bit more on the use case you mentioned.

>And a minor point; Table in Section 6 lists &#8220;Section 4&#8221;, which should be Section 2.

Sorry about that. Thanks for pointing. Will correct in the next update.

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: [email-masked]
Website: http://www.tcs.com
____________________________________________
Experience certainty.	IT Services
Business Solutions
Consulting
____________________________________________

-----"Dijk, Esko" <[email-masked]> wrote: -----

>To: Abhijan Bhattacharyya <[email-masked]>,
>"[email-masked]" <[email-masked]>
>From: "Dijk, Esko" <[email-masked]>
>Date: 01/27/2015 10:34PM
>Subject: CoAP No-Response: use with NON only?
>
>
>
>
>
>
>
>
>
>Hello Abhijan,
> 
>The use of the option with NON only is not made crystal clear yet:
>&#8220;primarily intended to be used with non-confirmable update requests
>(e.g., PUT) and should have no effect
> if used with a CON  request.&#8221; leaves open an implementation where it
>does work with CON and leaves clients free to use it with CON.
>However Section 1 states &#8220;At present this option will have no effect
>if used with confirmable (CON) mode.&#8221; Which is saying it
> musn&#8217;t work with CON on the server side.
> 
>I would like to question this NON-only behavior. Why not make it work
>for CON as well? Use case: my client is frequently POSTing  to a
>specific resource. However the resource
> returns a big data blob in the response always, which the client is
>not interested in. Client would like to use No-Response to stop
>receiving the big data blob all the time.
>If CON is unwanted for certain reasons perhaps it should be explained
>in the I-D? One possible reason could be that supporting the option
>for CON is more implementation effort
> in a CoAP server. Maybe I just missed the part where this is
>explained.
> 
>And a minor point; Table in Section 6 lists &#8220;Section 4&#8221;, which should
>be Section 2.
> 
>Esko
> 
>A modified version of the No-Response draft has been submitted. This
>draft has so far addressed all the technical comments received during
>the past meetings and mailing list discussions. We would
> urge the CoRE members to do a review of the draft and share their
>comments. Also, would request people to implement this option.
>
>
>
>
>Regards
>
>Abhijan Bhattacharyya
>
>Associate Consultant
>
>Mailto: [email-masked]
>
>Website: http://www.tcs.com
>
>From:        [email-masked]
>
>
>To:        Soma Bandyopadhyay <[email-masked]>, "Abhijan
> Bhattacharyya" <[email-masked]>, "Arpan Pal"
><[email-masked]>, Arpan Pal <[email-masked]>, "Soma
>Bandyopadhyay"
> <[email-masked]>, Abhijan Bhattacharyya
><[email-masked]>
>
>
>Date: ÿ ÿ ÿ ÿ01/21/2015 05:57 PM
>
>
>Subject: ÿ ÿ ÿ ÿNew Version Notification for
>draft-tcs-coap-no-response-option-08.txt
>
>
>
>
>
>
>
>
>
>
>
>
>Name:
>ÿdraft-tcs-coap-no-response-option
>
>Revision: ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ 08
>
>Title: ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿCoAP option for no
>server-response
>
>Document date: ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ 2015-01-21
>
>Group: ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿIndividual Submission
>
>Pages: ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ ÿ17
>
>URL:
>ÿhttp://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-optio
>n-08.txt
>
>Status:
>https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/
>
>Htmlized:
>http://tools.ietf.org/html/draft-tcs-coap-no-response-option-08
>
>Diff:
>http://www.ietf.org/rfcdiff?url2=draft-tcs-coap-no-response-option-08
>
>
>
>Abstract:
>
>ÿ There can be typical M2M scenarios where responses from server
>
>ÿ against request from client might be considered redundant. This
>kind
>
>ÿ of open-loop exchange (with no reverse path from the server to the
>
>ÿ client) may be typically desired to minimize resource consumption
>in
>
>ÿ constrained systems while simultaneously updating a bulk of
>
>ÿ resources or updating a resource with a very high frequency. CoAP
>
>ÿ already provides a non-confirmable (NON) mode of exchange where the
>
>ÿ server end-point does not respond with ACK. However, the server
>end-
>
>ÿ point responds back with a status code indicating "the result of
>the
>
>ÿ attempt to understand and satisfy the request".
>
>
>
>ÿ This draft introduces a header option for CoAP called
>'No-Response'.
>
>ÿ The option explicitly tells the server to suppress responses about
>
>ÿ the state of the resource against the request from the client. This
>
>ÿ option also provides granular control by allowing suppression of a
>
>ÿ typical class or a combination of classes of responses. This option
>
>ÿ may be effective for both unicast and multicast requests. This
>draft
>
>ÿ discusses few exemplary applications which might benefit from this
>
>ÿ option.
>
>
>
>
>ÿ ÿ ÿ ÿ ÿ ÿ
>
>
>
>
>
>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: "Dijk, Esko" <[email-masked]>
Date: Wed, 28 Jan 2015 06:56:32 +0000

Thanks,

My suggestion is for the language on CON to make this more clear in a future version. It is fine for me to "leave the door open for CON" at this point in time. Eventually if this would become  a WG draft, it is important for interoperability that we avoid e.g. a client expects to use CON + No-Resp and the server raises an error on receiving CON + No-Resp.

Furthermore, in COAP conceptually the message layer is separated from the request+response layer. So the decision of providing an ACK yes or no is in some implementations separated from the decision to provide a response yes or no. So it may be *more* implementation effort to support a NON + No-Response only, than to support both CON/NON with No-Response. That's a reason perhaps not to limit the option to NON only. (Some input from CoAP implementers needed here...)

The use case I mention is purely hypothetical. But not unthinkable. We may not want to artificially limit the scope of a No-Response option to NONs only, just because the use case is not visible yet. (A use case may come over the next years.)  Of course we should not put much effort to support a "maybe" use case, only support it if the functionality comes for free.

Esko

From: Abhijan Bhattacharyya [mailto:[email-masked]]
Sent: Wednesday, January 28, 2015 05:21
To: Dijk, Esko
Cc: [email-masked]; Soma Bandyopadhyay; Arpan Pal
Subject: Re: CoAP No-Response: use with NON only?

Hi Esko,

>"primarily intended to be used with non-confirmable update requests

> if used with a CON  request."  ..... "At present this option will have no effect

>if used with confirmable (CON) mode."

Regards
Abhijan Bhattacharyya
Associate Consultant

-----"Dijk, Esko" <[email-masked]<mailto:[email-masked]>> wrote: -----

>To: Abhijan Bhattacharyya <[email-masked]<mailto:[email-masked]>>,
>"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
>From: "Dijk, Esko" <[email-masked]<mailto:[email-masked]>>
>Date: 01/27/2015 10:34PM
>"primarily intended to be used with non-confirmable update requests
> if used with a CON  request." leaves open an implementation where it
>However Section 1 states "At present this option will have no effect
>if used with confirmable (CON) mode." Which is saying it
> musn't work with CON on the server side.
>
>To: [email-masked]<mailto:[email-masked]>
>
>To:        Soma Bandyopadhyay <[email-masked]<mailto:[email-masked]>>, "Abhijan
> Bhattacharyya" <[email-masked]<mailto:[email-masked]>>, "Arpan Pal"
><[email-masked]<mailto:[email-masked]>>, Arpan Pal <[email-masked]<mailto:[email-masked]>>, "Soma
>Bandyopadhyay"
> <[email-masked]<mailto:[email-masked]>>, Abhijan Bhattacharyya
><[email-masked]<mailto:[email-masked]>>
>
>
> draft-tcs-coap-no-response-option
>
>Revision:                 08
>
> http://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-optio
>n-08.txt
>
>Status:

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 28 Jan 2015 09:14:45 +0100

> “primarily intended to be used with non-confirmable update requests
> (e.g., PUT) and should have no effect if used with a CON  request.”

Hmm, I'm not sure we should make option semantics depend on a detail
(CON vs. NON) at the message layer.

"This appears to be more useful with NON" is sage advice, but the
request/response layer shouldn't have to react differently based on
message layer proceedings.

Grüße, Carsten