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

From: Abhijan Bhattacharyya <[email-masked]>
Date: Tue, 8 Oct 2013 15:52:00 +0530

Dear All,
A new version for the No-Resp option is uploaded. This version tries to address all the comments received on the last version. The key modifications in this version are as below:

1. A guideline on applicability of this option with the 4 REST methods is provided
2. Interpretation of the 1 bit option values is changed
3. The examples section is re-organised and 2 examples with POST is incorporated

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 10/08/2013 03:46PM ----- 
To: Abhijan Bhattacharyya <[email-masked]>, Soma Bandyopadhyay <[email-masked]>, Arpan Pal <[email-masked]>
From: [email-masked]
Date: 10/08/2013 03:43PM
Subject: New Version Notification for draft-tcs-coap-no-response-option-03.txt

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

Filename: draft-tcs-coap-no-response-option
Revision: 03
Title: CoAP option for no server-response
Creation date: 2013-10-08
Group: Individual Submission
Number of pages: 16
URL:             http://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-03.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-03
Diff:            http://www.ietf.org/rfcdiff?url2=draft-tcs-coap-no-response-option-03

Abstract:
   There can be typical M2M scenarios where responses from the data
   sink to the data source against request/ notification from the
   source might be considered redundant. This kind of open-loop
   exchange (with no reverse path from the sink to the source) may be
   desired while updating resources or notifying about the updated
   status of a resource in constrained systems looking for maximized
   throughput with minimized resource consumption. CoAP already
   provides a non-confirmable (NON) mode of exchange where The
   receiving end-point does not respond with ACK. However, the
   receiving end-point responds the sender with a status code
   indicating "the result of the attempt to understand and satisfy the
   request".

   This draft introduces a header option: 'No-Resp' to suppress
   responses from the receiver and discusses exemplary use cases which
   motivated this proposition based on real experience. This option
   also provides granularity by allowing suppression of a typical class
   or a combination of classes of responses. This option is applicable
   for both request/ response as well as resource-observe mode and may
   be effective for both unicast and multicast scenarios.

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: Tue, 8 Oct 2013 12:40:45 +0200

Hi Abhijan,

thanks for the update.

A quick reaction to the new table 2:

While it is true that the default value for the option is not very useful with GET, setting specific bits might still make it useful.  I think it would be worthwhile thinking about this.
(More generally speaking, having examples for the option bits would be useful for the other methods as well.  If they are hard to come up with -- maybe we don't need the option bits?)

Nits:

"empty or 0 value" -- for a uint, 0 is usually represented as an empty value.
So talking about 0 would be enough.  I would also do this in the examples.
(For comparison, the Observe option currently is slightly more complex*) by saying that the request option is empty and the response option is a uint; here, the option always is a uint.)

One other comment that just came to mind now:
Similar to HTTP header names, CoAP option names usually use full words (unless there is a commonly used abbreviation, such as URI or "Max"; the latter was just copied from HTTP.)
There is no point in trying to optimize the length of the option name, as the option number being encoded is a small integer anyway.
So it would seem to be more in style with the rest of CoAP to call the option "No-Response".

Grüße, Carsten

*) Which is out of character with the other CoAP options, each of which has a single encoding (which does simplify implementation somewhat).  Of course, it is easy to implement Observe as always being uint, so maybe that is not really an issue.

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Tue, 8 Oct 2013 17:44:09 +0530

Hi Carsten,

>While it is true that the default value for the option is not very
>useful with GET, setting specific bits might still make it useful.  I
>think it would be worthwhile thinking about this.
>(More generally speaking, having examples for the option bits would
>be useful for the other methods as well.  If they are hard to come up
>with -- maybe we don't need the option bits?)

Any value for this option should be treated as 'DON'T CARE' (like digital logic) for GET or DELETE. In fact these methods ideally should not use this option. That is why no values were specified and no examples were illustrated for GET and DELETE. Still, do you think it will be useful if we  specify a default value like '7' (specifying all responses to be allowed) for GET and DELETE? Or, may be, we put some examples showing that although we use this option with whatever value still that does not have any effect on the exchanges?

>(For comparison, the Observe option currently is slightly more
>complex*) by saying that the request option is empty and the response
>option is a uint; here, the option always is a uint.)

Actually the idea was that there may be applications which would benefit by not allowing any response. So in such a case the application will not require any granularity and hence may save 1 byte (which may be significant overhead for very small sized updates) by using it as empty. But yes we can simplify things if we keep it as 1 byte uint.

>Similar to HTTP header names, CoAP option names usually use full
>words (unless there is a commonly used abbreviation, such as URI or
>"Max"; the latter was just copied from HTTP.)
>There is no point in trying to optimize the length of the option
>name, as the option number being encoded is a small integer anyway.

Agreed and accepted.

Regards
Abhijan Bhattacharyya
Associate Consultant

-----Carsten Bormann <[email-masked]> wrote: -----

>To: Abhijan Bhattacharyya <[email-masked]>
>From: Carsten Bormann <[email-masked]>
>Date: 10/08/2013 04:11PM
>Cc: <[email-masked]>, Arpan Pal <[email-masked]>
>Subject: Re: [core] Fw: New Version Notification for
>draft-tcs-coap-no-response-option-03.txt
>
>
>Hi Abhijan,
>
>thanks for the update.
>
>While it is true that the default value for the option is not very
>useful with GET, setting specific bits might still make it useful.  I
>think it would be worthwhile thinking about this.
>(More generally speaking, having examples for the option bits would
>be useful for the other methods as well.  If they are hard to come up
>with -- maybe we don't need the option bits?)
>
>Nits:
>
>(For comparison, the Observe option currently is slightly more
>complex*) by saying that the request option is empty and the response
>option is a uint; here, the option always is a uint.)
>
>Similar to HTTP header names, CoAP option names usually use full
>words (unless there is a commonly used abbreviation, such as URI or
>"Max"; the latter was just copied from HTTP.)
>There is no point in trying to optimize the length of the option
>name, as the option number being encoded is a small integer anyway.
>*) Which is out of character with the other CoAP options, each of
>which has a single encoding (which does simplify implementation
>somewhat).  Of course, it is easy to implement Observe as always
>being uint, so maybe that is not really an issue.

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 8 Oct 2013 16:02:20 +0300

The idea of suppressing responses has been floating around for some
time, so it's good to see that someone finally started to write it
down.

I've got a few comments/questions:

* How does it work across proxies?
For example, normally a proxy is free to satisfy a request as it sees
fit; is a proxy required to include the No-Resp option in its request
if the original client doesn't want a response? What should happen
when a proxy does not implement the option?

* How does it interact with caches?
For example, if there is no response, cache entries do not get
invalidated; is this intended?

* I'm not sure what a No-Resp option in a notification/response does.
If a message is non-confirmable, then there is already no message
coming back from the recipient.

* Regarding high-frequency/real-time updates: Just because the sender
does not have to wait for a response doesn't mean that it can send as
frequently as it likes. Since there is no return traffic from the
recipient, the sender cannot monitor packet loss and cannot estimate
the RTT. This means the sender "SHOULD NOT send more than one UDP
datagram every 3 seconds, and SHOULD use an even less aggressive rate
when possible." (rfc5405)

* There is no need for short option names, since the names are not
included in the message. Why not "No-Response"? Or maybe
"Response-Filter"?

* Is the option intended to be critical or elective?

* If, for example, only 2.xx responses are suppressed and an error
occurs, the non-confirmable 4.xx/5xx response could get lost. This
could leave the impression that the request was successful. It might
be worth pointing out that this is not the case.

* How does a sender detect if it's sending its data to a recipient
that is long gone?

* Should a recipient be able to detect if consecutive messages were reordered?

* There is no need to distinguish between a 0-byte/empty value and the
1-byte value 0b00000000. Both encode the same uint.

* The bit field (table 3) could be slightly simplified by setting the
bits according to the response classes:

00000000 suppress all responses
00000010 allow 2.xx
00001000 allow 4.xx
00010000 allow 5.xx

* "Thus, if the client decides to open up the responses for errors
(4.xx & 5.xx) then it has to wait for the entire time-out period" --
CoAP does not define a time-out period for responses, only for
acknowledgements/resets.

* When can the token in a request with No-Resp option be reused?

* The path and query in the example in figure 3 should be split in
multiple options:

Uri-Path: "insertInfo"
Uri-Query: "VehID=00"
Uri-Query: "RouteID=DN47"
Uri-Query: "Lat=22.5649015"
Uri-Query: "Long=88.4103511667"
Uri-Query: "Time=2013-01-13T11:24:51"

As an observation, non-confirmable PUTs with No-Resp option seem to
provide a similar service as draft-ietf-core-observe, but much more
lightweight.

When comparing the two approaches, it's clear that No-Resp appears
that way because -observe simply does a lot more: -observe scales from
a single recipient to huge numbers of recipients by the use of
proxies, implements congestion control, detects when recipients are
gone, and provides message reordering detection. Most of this was
formulated by the working group as a strong requirement for -observe.

However, when people bring up the idea of suppressing responses, they
are usually happy to give up all of this. That puzzles me.

Best regards,
Klaus

On 8 October 2013 13:22, Abhijan Bhattacharyya
<[email-masked]> wrote:
> Dear All,
> A new version for the No-Resp option is uploaded. This version tries to
> address all the comments received on the last version. The key modifications
> in this version are as below:
>

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Thu, 10 Oct 2013 01:05:17 +0530

Hi Claus,
First of all, thanks for your detailed feedback on the draft.  We would like to clear the fact that this option is no way conceived as a substitute to the versatile and "well thought of" resource-observe option. However, there may be certain situations where the No-Response option may appear as a more lightweight way of performing stuffs with lower complexity. 
Addressing comments from you and Carsten, we have submitted a new version of draft which is available at:  http://tools.ietf.org/html/draft-tcs-coap-no-response-option-04

Requesting your feedback on this version please.

> when a proxy does not implement the option?

This option is presently NOT to be forwarded by proxies and hence no caching. We have explained this in the text below Table 1 in section 4. However, this issue can be kept as an open question for experts to comment on. 

> coming back from the recipient.

This option has no effect for notifications. Examples in the previous versions created the confusion. Requesting you to please check the section 5.2.

> when possible." (rfc5405)

Yes. What we mean is that this option gets rid of the dependency on the reverse path completely where possible. The application is free to choose the update rates according to the system being developed (abiding by the prescribed bounds).

> included in the message. Why not "No-Response"? Or maybe

Agreed. Reflected in the present version. Carsten already commented the same. "Response-Filter" is lucrative, but we are keeping "No-Response" for now to maintain the consistency. Further name changes can be taken up later.

> * Is the option intended to be critical or elective?
Elective. This was already mentioned in the draft. But not in the standard way of CoAP spec. We have modified the table format. please check Table 1.

> * How does a sender detect if it's sending its data to a recipient

Addressed these points. Please refer to the enhanced implementation note in section 4.1

> * Should a recipient be able to detect if consecutive messages were reordered?
Keeping this open. Would be good if we get some expert comments.

> 1-byte value 0b00000000. Both encode the same uint.

Accepted. Received same comment from Carsten.

> 00000000 suppress all responses

Accepted. Reflected in the draft. Please check modified table 3. In fact this scheme will have one far-sighted advantage. This keeps the option open for incorporating 3.xx responses as well if required in future. Recently was hearing few conversations on 3.xx responses though actions on that does not seem imminent.

> CoAP does not define a time-out period for responses, only for
Definitely not specified by CoAP. The term 'application specific' was missing. Please refer to the new description.

> * When can the token in a request with No-Resp option be reused?
Again, keeping it open for now.

> Uri-Query: "Time=2013-01-13T11:24:51"

Addressed. modified accordingly. Please check new figure 3.

Regards
Abhijan Bhattacharyya
Associate Consultant

-----Klaus Hartke <[email-masked]> wrote: -----
To: Abhijan Bhattacharyya <[email-masked]>
From: Klaus Hartke <[email-masked]>
Date: 10/08/2013 06:33PM
Cc: "[email-masked] WG" <[email-masked]>, Arpan Pal <[email-masked]>
Subject: Re: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-03.txt

Uri-Path: "insertInfo"
Uri-Query: "VehID=00"

Best regards,
Klaus

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 18 Oct 2013 23:09:56 +0300

Hi Abhijan,

> This option is presently NOT to be forwarded by proxies and hence no
> caching. We have explained this in the text below Table 1 in section 4.
> However, this issue can be kept as an open question for experts to comment
> on.

Not forwarding the No-Response option across proxies is probably okay,
although this limits the applicability of the option a bit.

However, caches can not only be located at proxies; they can also be
employed by clients and servers. So the draft should clearly describe
how the option interacts with caches.

>> * Regarding high-frequency/real-time updates: [...]
>
> Yes. What we mean is that this option gets rid of the dependency on
> the reverse path completely where possible. The application is free to
> choose the update rates according to the system being developed
> (abiding by the prescribed bounds).

So how does the No-Response option provide a higher throughput/less
latency compared to non-confirmable notifications when using
draft-ietf-core-observe?

For high-frequency updates it might be even better to use confirmable
messages, because the acknowledgement allows the sender to send the
next update immediately instead of in a fixed interval.

I would even suspect that confirmable messages actually help in the
reduction in network clogging, because the sender can actually assess
the network conditions and does not send blindly more and more traffic
into the network. Do you happen to have some measurements on the
impact of confirmable and non-confirmable messages on network
clogging?

> Elective. This was already mentioned in the draft. But not in the standard
> way of CoAP spec. We have modified the table format. please check Table 1.

The table shows a default value of 0; it should probably be 31 (all
bits set - no response suppressed). Apart from that it looks good.

Option number 22 is currently not in use. You could put that into the
draft to allow people to experiment with the No-Response option more
easily.

> Addressed these points. Please refer to the enhanced implementation note in

How does the sender start sending again when the recipient actually
didn't go away permanently but there was a problem in the network
temporarily?

> Keeping this open. Would be good if we get some expert comments.

I'm asking you :-) What's your opinion?

Best regards,
Klaus

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Mon, 21 Oct 2013 15:09:42 +0530

Hi Klaus,

>how the option interacts with caches.
==================================
Probably there wont be too much effect so far as response caching is 
concerned for cases when the cache is located in the end-point. If the 
option is used in its original form, i.e., no response with 0 then 
obviously response caching is immaterial. If used with response filtering 
(borrowing your suggestion!) then for success we are any way not going to 
cache the responses. The 2.05 response does not arise as this option is 
not applicable for GET.

>latency compared to non-confirmable notifications when using
=======================================
Well, this option is originally conceived for suppressing all the 
responses. Suppress everything then client is freed of all closed loop 
constrains (other than the suggested interval which may be customized if 
the system allows). Now, one more point to be re-emphasized (as already 
mentioned in the latest version of the draft) is that while comparing with 
observe probably we need to consider the fact that this option just 
provides  a low cost request/response type exchange (where there can only 
be requests and optionally filtered or no response) for typical 
applications where the application compromises for a better trade-off. 
There may be scenarios where designing the infrastructure with this kind 
of compromised approach may be acceptable as a bit simpler way to do just 
the desirable. 'Observe' has a much greater spectrum and is indeed an 
elegant solution. But sometimes simple stuffs just befits in the groove 
enough to get the system going. May be we should look into the solution 
from that aspect! :)

>impact of confirmable and non-confirmable messages on network
=====================================
The proposed option is a result of experiments on field trials and 
emulated environments over several man-months. We have provided some hints 
of the deployment while describing the 1st use case. We can surely share 
the experimental setups and few results once we get an opportunity to 
present in the Vancouver meeting. 

Firstly, the update interval requirement may not necessarily be decided by 
the client. It can, under many circumstances, be defined by the use case. 
For example, in our case the requirements were to be provided by the 
engineers developing the algorithms for running analytics at the back end. 
It was like "how frequent samples do I need and how much loss in samples 
can I tolerate to run the XYZ analytics".

Secondly, the  CON mode was not good enough. We examined the message 
flights for each updates through packet captures. In practice, there were 
situations where we suffered from duplicated transmissions due to the 
delayed arrivals of ACKs piggybacked with responses. 

>bits set - no response suppressed). Apart from that it looks good.
=================================
Thanks. But we would like to stick to 0 as the default with the assumption 
that if one decides to introduce this option in the request message then 
probably the intention is to suppress responses (assuming 'suppress all' 
is the usual wish). A default of 0 would be desirable then in the usual 
case. But if we get a consensus on keeping all open then we can always do 
that. Not really a big deal.

>draft to allow people to experiment with the No-Response option more
=================================
Thanks for the suggestion. Will propose that in the meeting.

>> Addressed these points. Please refer to the enhanced implementation
>note in
>> section 4.1
>
=================================
Well, is it not the similar situation when we browse for a given site get 
some responses like 'Server busy' or 'The website is temporary 
unavailable', etc. and then we retry using some personalized heuristic 
interval? :) May be application developer can do something like that here 
also. Only thing is that the retry should have all the responses open.

>>> * Should a recipient be able to detect if consecutive messages
>were
>>> reordered?
>>
=================================
Would it be very different than the usual NON PUT/POST cases? Bit confused 
on that really! :(

Finally, thanks for such detail observations. Conversations like this are 
indeed of immense help in the learning curve of an "IETF-newbie". :)

Regards
Abhijan Bhattacharyya
Associate Consultant

From:
Klaus Hartke <[email-masked]>
To:
Abhijan Bhattacharyya <[email-masked]>
Cc:
Arpan Pal <[email-masked]>, "[email-masked] WG" <[email-masked]>
Date:
10/19/2013 01:40 AM
Subject:
Re: [core] Fw: New Version Notification for 
draft-tcs-coap-no-response-option-03.txt

Hi Abhijan,

> Addressed these points. Please refer to the enhanced implementation note 
in
> section 4.1

Best regards,
Klaus