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

From: Abhijan Bhattacharyya <[email-masked]>
Date: Fri, 30 Aug 2013 13:16:04 +0530

Dear All,
We have submitted a draft proposing a new option for CoAP. Would request 
your comments on this please. The details of the draft can be found below.

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services Limited
Mailto: [email-masked]
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Consulting
____________________________________________
----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 08/30/2013 01:13 PM 
-----

From:
[email-masked]
To:
Abhijan Bhattacharyya <[email-masked]>, Soma Bandyopadhyay 
<[email-masked]>, Arpan Pal <[email-masked]>
Date:
08/29/2013 06:09 PM
Subject:
New Version Notification for draft-tcs-coap-no-response-option-00.txt

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

Filename:                 draft-tcs-coap-no-response-option
Revision:                 00
Title:                            CoAP option for no server-response
Creation date:            2013-08-29
Group:                            Individual Submission
Number of pages: 8
URL:             
http://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-00.txt

Status:          
http://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option
Htmlized:        
http://tools.ietf.org/html/draft-tcs-coap-no-response-option-00

Abstract:
   The server end-point does not respond with acknowledgment (ACK) in
   non-confirmable(NON)mode of CoAP. However, the server responds the
   client with a status code indicating "the result of the attempt to
   understand and satisfy the request". But there may be typical
   scenarios, while updating resources in NON mode, where any kind of
   response from the server may be considered redundant. Thus, in this
   case, the transaction becomes completely open-loop with no reverse
   path from the server to the client. This kind of exchange may be
   useful in constrained systems looking for maximized throughput with
   minimized resource consumption. This draft introduces a header
   option: 'No-Resp' to suppress any response from the server and
   discusses an exemplary but practical use case which actually
   motivated this proposition based on real experience.

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 30 Aug 2013 13:06:03 +0200

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

---

From: Bert Greevenbosch <[email-masked]>
Date: Sat, 31 Aug 2013 06:28:31 +0000

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,
> 
> 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.
> 
> -- 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.
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core