Subject: [core] Handling tokens for No-response

From: Abhijan Bhattacharyya <[email-masked]>
Date: Mon, 14 Apr 2014 18:13:37 +0530

Hi All,
A comment received on the No-response option during the London meeting was 
on to clarify how to handle the tokens for requests that are not going to 
get any matching response. Specifically, concern was raised regarding the 
reuse of a token. A token is used to match the response with the 
corresponding request. Now, since no response is suppressing the request 
from the server so a token in the request is never matched with any 
response. Under such circumstance how to decide when to reuse a token.

The point was raised by Carsten. I had a very brief off-the-meeting 
discussion with him on this and getting opinion on this matter in the 
mailing list was suggested.
So, here are some specific questions to the mailing list:

1. Is the problem statement above really important enough to be dealt with 
in the draft or should it be left upon the application developer to 
handle?

(The following ones are relevant if the answer to the above is an 'yes' 
for proposing a solution. )
2. Assuming that we need a precise direction in the draft to handle this, 
would it be a good idea to suggest to use a zero-length token while using 
No-response? (Of course, this cannot be a MUST considering the fact that 
if someone wants use No-response with a GET request for observe 
cancellation then the token must be there to identify the correspondence 
with the original observe-GET. Please note:  No-response is not defined 
for GET in the present draft but it will be included in the next version 
keeping the observe cancellation solution in mind ) 

3. Any other idea? 

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
____________________________________________
=====-----=====-----=====
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: "Rahman, Akbar" <[email-masked]>
Date: Wed, 16 Apr 2014 01:15:45 -0400

Hi Abhijan,

I would prefer that the no-response token handling be left up to the
implementer to handle.  This is because there is already a few other
cases where a response may be suppressed by the server especially for
congestion control and multicast response suppression.  See for example:

http://tools.ietf.org/html/draft-ietf-core-groupcomm-18#section-2.8

Best Regards,

Akbar

From: core [mailto:[email-masked]] On Behalf Of Abhijan
Bhattacharyya
Sent: Monday, April 14, 2014 8:44 AM
To: [email-masked]
Subject: [core] Handling tokens for No-response

Hi All, 
A comment received on the No-response option during the London meeting
was on to clarify how to handle the tokens for requests that are not
going to get any matching response. Specifically, concern was raised
regarding the reuse of a token. A token is used to match the response
with the corresponding request. Now, since no response is suppressing
the request from the server so a token in the request is never matched
with any response. Under such circumstance how to decide when to reuse a
token. 

1. Is the problem statement above really important enough to be dealt
with in the draft or should it be left upon the application developer to
handle? 

(The following ones are relevant if the answer to the above is an 'yes'
for proposing a solution. ) 
2. Assuming that we need a precise direction in the draft to handle
this, would it be a good idea to suggest to use a zero-length token
while using No-response? (Of course, this cannot be a MUST considering
the fact that if someone wants use No-response with a GET request for
observe cancellation then the token must be there to identify the
correspondence with the original observe-GET. Please note:  No-response
is not defined for GET in the present draft but it will be included in
the next version keeping the observe cancellation solution in mind ) 

3. Any other idea? 

Regards
Abhijan Bhattacharyya
Associate Consultant
Website: http://www.tcs.com <http://www.tcs.com/>

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Wed, 16 Apr 2014 15:12:16 +0530

Hi Akbar,
Thank you very much for sharing your views. Yes, both the situations are 
logically similar excepting the fact that in the multicast case the 
decision is taken by the server and in the later case client explicitly 
expresses the disinterest in responses.

Regards
Abhijan Bhattacharyya
Associate Consultant

From:
"Rahman, Akbar" <[email-masked]>
To:
"Abhijan Bhattacharyya" <[email-masked]>
Cc:
<[email-masked]>
Date:
04/16/2014 10:50 AM
Subject:
RE: [core] Handling tokens for No-response

Hi Abhijan,

I would prefer that the no-response token handling be left up to the 
implementer to handle.  This is because there is already a few other cases 
where a response may be suppressed by the server especially for congestion 
control and multicast response suppression.  See for example:

Best Regards,

Akbar

Hi All, 

3. Any other idea? 

Regards
Abhijan Bhattacharyya
Associate Consultant

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 16 Apr 2014 13:04:48 +0000

Hello Abhijan, Akbar,

just thinking how a client would decide on Token re-use : there seem to be 3 cases.

1. When sending a unicast CON request and no response is given or the client asks for No-Response, I would think that the Token can be re-used after EXCHANGE_LIFETIME. Is that right?
2. When sending a unicast NON request and no response is given or the client asks for No-Response,I would assume Token can be re-used after MAX_RTT.
3. When sending a multicast NON request, the Token can be re-used after MAX_RTT in any case, even if some responses are already received. (There could always be coming more responses within MAX_RTT so the request is still 'active' in this sense.)

To make this simpler we could also say that Tokens can be safely re-used after EXCHANGE_LIFETIME since always EXCHANGE_LIFETIME >= MAX_RTT.
So I feel that this Token lifetime question is relevant for a wider context than just related to the No-Response Option; like Akbar said also.

Suppose we would advise to use a zero-length (default) Token for such requests - wouldn't there be the same problem of Token re-use? I.e. I can only re-use the 0 Token after EXCHANGE_LIFETIME time has passed.

regards
Esko

From: core [mailto:[email-masked]] On Behalf Of Abhijan Bhattacharyya
Sent: Wednesday, April 16, 2014 11:42
To: Rahman, Akbar
Cc: [email-masked]
Subject: Re: [core] Handling tokens for No-response

Hi Akbar,
Thank you very much for sharing your views. Yes, both the situations are logically similar excepting the fact that in the multicast case the decision is taken by the server and in the later case client explicitly expresses the disinterest in responses.

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

From:

"Rahman, Akbar" <[email-masked]<mailto:[email-masked]>>

To:

"Abhijan Bhattacharyya" <[email-masked]<mailto:[email-masked]>>

Cc:

<[email-masked]<mailto:[email-masked]>>

Date:

04/16/2014 10:50 AM

Subject:

________________________________

Hi Abhijan,

I would prefer that the no-response token handling be left up to the implementer to handle.  This is because there is already a few other cases where a response may be suppressed by the server especially for congestion control and multicast response suppression.  See for example:

Best Regards,

Akbar

From: core [mailto:[email-masked]] On Behalf Of Abhijan Bhattacharyya
Sent: Monday, April 14, 2014 8:44 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [core] Handling tokens for No-response

Hi All,
A comment received on the No-response option during the London meeting was on to clarify how to handle the tokens for requests that are not going to get any matching response. Specifically, concern was raised regarding the reuse of a token. A token is used to match the response with the corresponding request. Now, since no response is suppressing the request from the server so a token in the request is never matched with any response. Under such circumstance how to decide when to reuse a token.

The point was raised by Carsten. I had a very brief off-the-meeting discussion with him on this and getting opinion on this matter in the mailing list was suggested.
So, here are some specific questions to the mailing list:

1. Is the problem statement above really important enough to be dealt with in the draft or should it be left upon the application developer to handle?

(The following ones are relevant if the answer to the above is an 'yes' for proposing a solution. )
2. Assuming that we need a precise direction in the draft to handle this, would it be a good idea to suggest to use a zero-length token while using No-response? (Of course, this cannot be a MUST considering the fact that if someone wants use No-response with a GET request for observe cancellation then the token must be there to identify the correspondence with the original observe-GET. Please note:  No-response is not defined for GET in the present draft but it will be included in the next version keeping the observe cancellation solution in mind )

3. Any other idea?

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

________________________________
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: "Rahman, Akbar" <[email-masked]>
Date: Wed, 16 Apr 2014 14:57:30 -0400

Hi Esko,

> 1. When sending a unicast CON request and no response is given or the
client asks for No-Response, I would think that the Token can be re-used
after EXCHANGE_LIFETIME. Is that right?

Yes, that would be my interpretation as well.

> Suppose we would advise to use a zero-length (default) Token for such
requests - wouldn't there be the same problem of Token re-use? I.e. I
can only re-use the 0 Token after EXCHANGE_LIFETIME time has passed.

Yes, good point!

/Akbar

 

From: Dijk, Esko [mailto:[email-masked]] 
Sent: Wednesday, April 16, 2014 9:05 AM
To: Abhijan Bhattacharyya; Rahman, Akbar
Cc: [email-masked]
Subject: RE: [core] Handling tokens for No-response

Hello Abhijan, Akbar,

just thinking how a client would decide on Token re-use : there seem to
be 3 cases.

1. When sending a unicast CON request and no response is given or the
client asks for No-Response, I would think that the Token can be re-used
after EXCHANGE_LIFETIME. Is that right?

2. When sending a unicast NON request and no response is given or the
client asks for No-Response,I would assume Token can be re-used after
MAX_RTT.

3. When sending a multicast NON request, the Token can be re-used after
MAX_RTT in any case, even if some responses are already received. (There
could always be coming more responses within MAX_RTT so the request is
still 'active' in this sense.)

To make this simpler we could also say that Tokens can be safely re-used
after EXCHANGE_LIFETIME since always EXCHANGE_LIFETIME >= MAX_RTT.

So I feel that this Token lifetime question is relevant for a wider
context than just related to the No-Response Option; like Akbar said
also.

Suppose we would advise to use a zero-length (default) Token for such
requests - wouldn't there be the same problem of Token re-use? I.e. I
can only re-use the 0 Token after EXCHANGE_LIFETIME time has passed.

regards

Esko

Hi Akbar, 

Regards
Abhijan Bhattacharyya
Associate Consultant

From: 

To: 

Cc: 

<[email-masked]> 

Date: 

04/16/2014 10:50 AM 

Subject: 

Hi Abhijan, 

http://tools.ietf.org/html/draft-ietf-core-groupcomm-18#section-2.8
<http://tools.ietf.org/html/draft-ietf-core-groupcomm-18#section-2.8>  

Best Regards, 

Akbar 

From: core [mailto:[email-masked] <mailto:[email-masked]>
] On Behalf Of Abhijan Bhattacharyya
Sent: Monday, April 14, 2014 8:44 AM
To: [email-masked]
Subject: [core] Handling tokens for No-response 
  
Hi All, 

3. Any other idea? 

Regards
Abhijan Bhattacharyya
Associate Consultant
<mailto:[email-masked]> 

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: "weigengyu" <[email-masked]>
Date: Thu, 17 Apr 2014 18:14:51 +0800

Hi， 

No response option seems to be a request/response (transaction) sublayer staff. 
A CON request with No Response option will also invoke a message sublayer ack accoring to CoAP semantics, 
so the traffic of message does not affect. 

And I do not think that using Zero length Token is a good way to use .
In some existing protocols, the transaction requestes are classified into command request and not command and it is identified by one-bit. 

My suggestion is to add one bit definition instead of using Zero length Token. 
And the significant time of Token should not change whether the No Resopnse option is used. 

Regards,

Gengyu

Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications

From: Rahman, Akbar 
Sent: Thursday, April 17, 2014 2:57 AM
To: Dijk, Esko 
Cc: Abhijan Bhattacharyya ; [email-masked] 
Subject: Re: [core] Handling tokens for No-response

Hi Esko,

 

> Suppose we would advise to use a zero-length (default) Token for such requests – wouldn’t there be the same problem of Token re-use? I.e. I can only re-use the 0 Token after EXCHANGE_LIFETIME time has passed.

Yes, good point!

/Akbar

 

Hello Abhijan, Akbar,

3. When sending a multicast NON request, the Token can be re-used after MAX_RTT in any case, even if some responses are already received. (There could always be coming more responses within MAX_RTT so the request is still ‘active’ in this sense.)

Suppose we would advise to use a zero-length (default) Token for such requests – wouldn’t there be the same problem of Token re-use? I.e. I can only re-use the 0 Token after EXCHANGE_LIFETIME time has passed.

regards

Esko

Hi Akbar, 

Regards
Abhijan Bhattacharyya
Associate Consultant

      From: 
     
      To: 
     
      Cc: 
     <[email-masked]> 
     
      Date: 
     04/16/2014 10:50 AM 
     
      Subject: 

--------------------------------------------------------------------------------

Hi Abhijan, 

Best Regards, 

Akbar 

Hi All, 

3. Any other idea? 

Regards
Abhijan Bhattacharyya
Associate Consultant

--------------------------------------------------------------------------------

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

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Thu, 17 Apr 2014 17:52:15 +0530

Hi Akbar, Esko, Gengyu,

Thanks for sharing your thoughts. 
The No-response option is currently defined only for NON requests. As 
rightly pointed out by Gengyu, using No-response for CON does not really 
save us on the traffic, etc. However, it might be useful to use 
No-response with CON for separate-response. But, that is not included in 
the draft as we did not envision a fitting use case for such a use of 
No-response.

We cannot, as a general proposition, get rid of tokens while using 
No-response considering potential use of this option with a GET  for 
proactive cancellation of an observe session (Ref: <1> section 3.8 of 
draft-ietf-core-observe-13 and <2> 
http://www.ietf.org/mail-archive/web/core/current/msg05331.html).  A GET 
request to cancel an observe session must carry a token to associate 
itself with the existing observe session. 

So, as elaborated by Esko, possibly it would be good to suggest some 
time-out (so its a MAY and not a MUST to give flexibility to the 
application developer as pointed out by Akbar ). The present draft adapts 
the definition of NON_LIFETIME as the reuse interval for message IDs. 
Would it be a good idea to adapt the same definition as the re-use 
interval for tokens also? The definition of NON_LIFETIME encompasses 
EXCHANGE_LIFETIME as well.

Regards
Abhijan Bhattacharyya
Associate Consultant

From:
"weigengyu" <[email-masked]>
To:
"Rahman, Akbar" <[email-masked]>, "Dijk, Esko" 
<[email-masked]>
Cc:
"Abhijan Bhattacharyya" <[email-masked]>, <[email-masked]>
Date:
04/17/2014 03:44 PM
Subject:
Re: [core] Handling tokens for No-response

Hi， 
 
No response option seems to be a request/response (transaction) sublayer 
staff. 
A CON request with No Response option will also invoke a message sublayer 
ack accoring to CoAP semantics, 
so the traffic of message does not affect. 
 
And I do not think that using Zero length Token is a good way to use .
In some existing protocols, the transaction requestes are classified into 
command request and not command and it is identified by one-bit. 
 
My suggestion is to add one bit definition instead of using Zero length 
Token. 
And the significant time of Token should not change whether the No 
Resopnse option is used. 

Regards,
 
Gengyu

From: Rahman, Akbar 
 
Hi Esko,

> Suppose we would advise to use a zero-length (default) Token for such 
requests ‐ wouldn’t there be the same problem of Token re-use? I.e. I can 
only re-use the 0 Token after EXCHANGE_LIFETIME time has passed.
 
Yes, good point!

/Akbar

 
 
Hello Abhijan, Akbar,
 
just thinking how a client would decide on Token re-use : there seem to be 
3 cases.
 
still ‘active’ in this sense.)
 
To make this simpler we could also say that Tokens can be safely re-used 
after EXCHANGE_LIFETIME since always EXCHANGE_LIFETIME >= MAX_RTT.
So I feel that this Token lifetime question is relevant for a wider 
context than just related to the No-Response Option; like Akbar said also.
 
Suppose we would advise to use a zero-length (default) Token for such 
requests ‐ wouldn’t there be the same problem of Token re-use? I.e. I can 
only re-use the 0 Token after EXCHANGE_LIFETIME time has passed.
 
regards
Esko

Hi Akbar, 

Regards
Abhijan Bhattacharyya
Associate Consultant

From: 

Hi Abhijan, 

Best Regards, 

Akbar 

Hi All, 

3. Any other idea? 

Regards
Abhijan Bhattacharyya
Associate Consultant

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 17 Apr 2014 15:08:23 +0200

On 17 Apr 2014, at 14:22, Abhijan Bhattacharyya <[email-masked]> wrote:

> We cannot, as a general proposition, get rid of tokens while using No-response considering potential use of this option with a GET  for proactive cancellation of an observe session (Ref: <1> section 3.8 of draft-ietf-core-observe-13 and <2>http://www.ietf.org/mail-archive/web/core/current/msg05331.html).  A GET request to cancel an observe session must carry a token to associate itself with the existing observe session. 

While this is true, this is not the point that I was making.
I was pointing out that a request that is defined in such a way that it MAY elicit a response (depending on some condition unknown to the client at the time) generates hardship for the client, because in the absence of a response it does not know whether it can retire the token or still has to expect a response for that.

Now if the client does not care about whether any response coming back is related back to the right request, it can reuse tokens at liberty.
(Including the zero-length token, which is in no way special, except that it is indeed shorter than any other token.)

> So, as elaborated by Esko, possibly it would be good to suggest some time-out (so its a MAY and not a MUST to give flexibility to the application developer as pointed out by Akbar ). The present draft adapts the definition of NON_LIFETIME as the reuse interval for message IDs. Would it be a good idea to adapt the same definition as the re-use interval for tokens also? The definition of NON_LIFETIME encompasses EXCHANGE_LIFETIME as well. 

In CoAP, we have timers at the message layer, not at the request/response layer.
Most clients will have a “patience” up to which they will expect a response, but we currently do not expose this at the protocol level.
(With some new option, the client could pose a deadline to the server, or the server could promise a deadline to the client.
http://tools.ietf.org/html/draft-bormann-coap-misc-26#appendix-B.4 has more about that.)

Grüße, Carsten

---

From: "weigengyu" <[email-masked]>
Date: Thu, 17 Apr 2014 23:51:15 +0800

Hi all,

In CoAP -18, page 34.
" An empty token value is appropriate e.g. when
no other tokens are in use to a destination, or when requests are
made serially per destination and receive piggy-backed responses.
There are however multiple possible implementation strategies to
fulfill this."

Does "An empty token value" mean "zero token length"?
Do it try to overload "no other tokens are in use to a destination" by No 
Response option?

Regards,

Gengyu

-----原始邮件----- 
From: Carsten Bormann
Sent: Thursday, April 17, 2014 9:08 PM
To: Abhijan Bhattacharyya
Cc: weigengyu ; Dijk, Esko ; Rahman, Akbar ; [email-masked]
Subject: Re: [core] Handling tokens for No-response

On 17 Apr 2014, at 14:22, Abhijan Bhattacharyya 
<[email-masked]> wrote:

> draft-ietf-core-observe-13 and 
> <2>http://www.ietf.org/mail-archive/web/core/current/msg05331.html).  A 
> GET request to cancel an observe session must carry a token to associate 

While this is true, this is not the point that I was making.
I was pointing out that a request that is defined in such a way that it MAY 
elicit a response (depending on some condition unknown to the client at the 
time) generates hardship for the client, because in the absence of a 
response it does not know whether it can retire the token or still has to 
expect a response for that.

Now if the client does not care about whether any response coming back is 
related back to the right request, it can reuse tokens at liberty.
(Including the zero-length token, which is in no way special, except that it 
is indeed shorter than any other token.)

> EXCHANGE_LIFETIME as well.

In CoAP, we have timers at the message layer, not at the request/response 
layer.
Most clients will have a $B!H(Bpatience$B!I(B up to which they will 
expect a response, but we currently do not expose this at the protocol 
level.
(With some new option, the client could pose a deadline to the server, or 
the server could promise a deadline to the client.
http://tools.ietf.org/html/draft-bormann-coap-misc-26#appendix-B.4 has more 
about that.)

Gr.AN|N_e, Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 22 Apr 2014 06:53:29 +0000

Hi,

if there's no time limit that can be defined for Token re-use, what time would an implementer of a client need to choose?   (I know we chose not to define 'patience' in CoAP, but an implementer would still need to make a sane choice here.) Can we argue that Patience i.e. max response delay will be "a few minutes" and hence Token can be re-used safely after a time far longer than that, say 15 minutes?

For those cases where the implementer of the CoAP client knows that a response may take very long (e.g. see OMA LWM2M case, "queue mode" function, where a response could take e.g. one day) he could adapt the Patience to something much longer.

Would that be a feasible approach?
I feel that it would be beneficial if the No-Response draft would say something about this Token re-use for unicast and multicast NON requests.  If several people in the CoRE WG saw it wrong, it may be worth pointing out as well to a non-CoRE audience ;)

Esko

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Thursday, April 17, 2014 15:08
To: Abhijan Bhattacharyya
Cc: weigengyu; Dijk, Esko; Rahman, Akbar; [email-masked]
Subject: Re: [core] Handling tokens for No-response

In CoAP, we have timers at the message layer, not at the request/response layer.
Most clients will have a "patience" up to which they will expect a response, but we currently do not expose this at the protocol level.
(With some new option, the client could pose a deadline to the server, or the server could promise a deadline to the client.
http://tools.ietf.org/html/draft-bormann-coap-misc-26#appendix-B.4 has more about that.)

Gr.AN|N_e, Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 22 Apr 2014 09:34:15 +0000

Hello Abhijan,

I forgot to mention that using  the No-Response Option is not a guarantee that no response will come. It actually MAY come since the Option is elective.
That is something that needs to be taken into account by a client in its Token re-use strategy. If not it leads to interoperability issues, or not?  E.g. "client expects no answer to its request with Token=0, so it sends out a new request with Token=0, but server does not recognize No-Response option, and sends a response, then the client receives the old delayed response with Token=0 instead of the newer response with same Token".

Esko

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Dijk, Esko
Sent: Tuesday, April 22, 2014 08:53
To: Carsten Bormann; Abhijan Bhattacharyya
Cc: [email-masked]
Subject: Re: [core] Handling tokens for No-response

Hi,

Esko

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Thursday, April 17, 2014 15:08
To: Abhijan Bhattacharyya
Cc: weigengyu; Dijk, Esko; Rahman, Akbar; [email-masked]
Subject: Re: [core] Handling tokens for No-response

Gr.AN|N_e, Carsten

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Wed, 23 Apr 2014 01:13:17 +0530

Hi Esko,
You are absolutely right. No-response is just to indicate the dis-interest of client about the response from server and if No-response is not implemented in server then it will always send a response. But this response should not have any importance to the client since the client is not interested in getting response.

Now, coming to your example, probably the consecutive responses should not matter much to the client if both the requests are made with No-response. However, say, if the first request is with No-response and the second request, with same token, is without No-response then a delayed response to the first one may be interpreted as a response to the second request (client needs a response in this case) if the gap between use of the same token is not enough.

>From the discussions so far, it seems we indeed need to define some timing value based on something like 'patience' or some 'promised deadline' as pointed out by Carsten. But, none of these are included into/ defined for the present main CoAP spec. Also, handling this issue may vary case to case depending the application feature.

So, would it not be a good idea to leave the token reuse to be handled by the application developer and to keep a note in the No-response draft which would effectively summarise the different technical aspects that we have been discussing on this topic.

Regards
Abhijan Bhattacharyya
Associate Consultant

-----"Dijk, Esko" <[email-masked]> wrote: -----
To: Abhijan Bhattacharyya <[email-masked]>
From: "Dijk, Esko" <[email-masked]>
Date: 04/22/2014 03:05PM
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [core] Handling tokens for No-response

Hello Abhijan,

Esko

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Dijk, Esko
Sent: Tuesday, April 22, 2014 08:53
To: Carsten Bormann; Abhijan Bhattacharyya
Cc: [email-masked]
Subject: Re: [core] Handling tokens for No-response

Hi,

Esko

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Thursday, April 17, 2014 15:08
To: Abhijan Bhattacharyya
Cc: weigengyu; Dijk, Esko; Rahman, Akbar; [email-masked]
Subject: Re: [core] Handling tokens for No-response

In CoAP, we have timers at the message layer, not at the request/response layer.
Most clients will have a "patience" up to which they will expect a response, but we currently do not expose this at the protocol level.
(With some new option, the client could pose a deadline to the server, or the server could promise a deadline to the client.
http://tools.ietf.org/html/draft-bormann-coap-misc-26#appendix-B.4ÿhas more about that.)

Gr;.A;N|;N_e, Carsten

---

From: "weigengyu" <[email-masked]>
Date: Wed, 23 Apr 2014 08:47:17 +0800

Hi all,

I agree that No-Response may need for some situations.

But the different between zero length of token and the value of  token being 
zeron should be clear.

Could anyone help to tell what does "An empty token value" in CoAP -18 mean?
Is it  the zero length token or the value of token being zero?

Regards,

Gengyu
Network Technogy Center
School of Computer

-----原始邮件----- 
From: Dijk, Esko
Sent: Tuesday, April 22, 2014 5:34 PM
To: Abhijan Bhattacharyya
Cc: [email-masked]
Subject: Re: [core] Handling tokens for No-response

Hello Abhijan,

I forgot to mention that using  the No-Response Option is not a guarantee 
that no response will come. It actually MAY come since the Option is 
elective.
That is something that needs to be taken into account by a client in its 
Token re-use strategy. If not it leads to interoperability issues, or not? 
E.g. "client expects no answer to its request with Token=0, so it sends out 
a new request with Token=0, but server does not recognize No-Response 
option, and sends a response, then the client receives the old delayed 
response with Token=0 instead of the newer response with same Token".

Esko

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Dijk, Esko
Sent: Tuesday, April 22, 2014 08:53
To: Carsten Bormann; Abhijan Bhattacharyya
Cc: [email-masked]
Subject: Re: [core] Handling tokens for No-response

Hi,

if there's no time limit that can be defined for Token re-use, what time 
would an implementer of a client need to choose?   (I know we chose not to 
define 'patience' in CoAP, but an implementer would still need to make a 
sane choice here.) Can we argue that Patience i.e. max response delay will 
be "a few minutes" and hence Token can be re-used safely after a time far 
longer than that, say 15 minutes?

For those cases where the implementer of the CoAP client knows that a 
response may take very long (e.g. see OMA LWM2M case, "queue mode" function, 
where a response could take e.g. one day) he could adapt the Patience to 
something much longer.

Would that be a feasible approach?
I feel that it would be beneficial if the No-Response draft would say 
something about this Token re-use for unicast and multicast NON requests. 
If several people in the CoRE WG saw it wrong, it may be worth pointing out 
as well to a non-CoRE audience ;)

Esko

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Thursday, April 17, 2014 15:08
To: Abhijan Bhattacharyya
Cc: weigengyu; Dijk, Esko; Rahman, Akbar; [email-masked]
Subject: Re: [core] Handling tokens for No-response

In CoAP, we have timers at the message layer, not at the request/response 
layer.
Most clients will have a "patience" up to which they will expect a response, 
but we currently do not expose this at the protocol level.
(With some new option, the client could pose a deadline to the server, or 
the server could promise a deadline to the client.
http://tools.ietf.org/html/draft-bormann-coap-misc-26#appendix-B.4 has more 
about that.)

Gr.AN|N_e, Carsten

________________________________
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: Wed, 23 Apr 2014 00:57:30 +0000

> Is it the zero length token or the value of token being zero?

In my understanding, "empty token value" means zero-length token.

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: core [mailto:[email-masked]] 代表 weigengyu
> 发送时间: 2014年4月23日 8:47
> 收件人: Dijk, Esko; Abhijan Bhattacharyya
> 抄送: [email-masked]
> 主题: Re: [core] Handling tokens for No-response
> 
> Hi all,
> 
> that no response will come. It actually MAY come since the Option is elective.
> That is something that needs to be taken into account by a client in its Token
> re-use strategy. If not it leads to interoperability issues, or not?
> E.g. "client expects no answer to its request with Token=0, so it sends out a
> new request with Token=0, but server does not recognize No-Response option,
> and sends a response, then the client receives the old delayed response with
> Token=0 instead of the newer response with same Token".
> 
> Esko
> 
> define 'patience' in CoAP, but an implementer would still need to make a sane
> choice here.) Can we argue that Patience i.e. max response delay will be "a few
> minutes" and hence Token can be re-used safely after a time far longer than
> that, say 15 minutes?
> 
> response may take very long (e.g. see OMA LWM2M case, "queue mode"
> function, where a response could take e.g. one day) he could adapt the
> Patience to something much longer.
> 
> I feel that it would be beneficial if the No-Response draft would say something
> about this Token re-use for unicast and multicast NON requests.
> If several people in the CoRE WG saw it wrong, it may be worth pointing out as
> well to a non-CoRE audience ;)
> 
> Esko
> 
> > <2>http://www.ietf.org/mail-archive/web/core/current/msg05331.html).
> > A GET request to cancel an observe session must carry a token to
> > associate itself with the existing observe session.
> 
> I was pointing out that a request that is defined in such a way that it MAY elicit
> a response (depending on some condition unknown to the client at the
> time) generates hardship for the client, because in the absence of a response it
> does not know whether it can retire the token or still has to expect a response
> for that.
> 
> > application developer as pointed out by Akbar ). The present draft
> > adapts the definition of NON_LIFETIME as the reuse interval for message IDs.
> Most clients will have a "patience" up to which they will expect a response, but
> we currently do not expose this at the protocol level.
> (With some new option, the client could pose a deadline to the server, or the
> server could promise a deadline to the client.
> 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, 23 Apr 2014 05:33:43 +0000

> In my understanding, "empty token value" means zero-length token.
Yes, this is specified in Section 3.2. - it defines "empty option value" and since Token is an option, empty Token is equal to a zero-length Token. And zero-length encodes the number 0 so that is the same thing as a Token with an explicit zero value put in.

Esko

-----Original Message-----
From: Likepeng [mailto:[email-masked]]
Sent: Wednesday, April 23, 2014 02:58
To: weigengyu; Dijk, Esko; Abhijan Bhattacharyya
Cc: [email-masked]
Subject: Re: [core] Handling tokens for No-response

Kind Regards
Kepeng

> But the different between zero length of token and the value of  token
> being zeron should be clear.
>
> I forgot to mention that using  the No-Response Option is not a
> guarantee that no response will come. It actually MAY come since the Option is elective.
> That is something that needs to be taken into account by a client in
> its Token re-use strategy. If not it leads to interoperability issues, or not?
> E.g. "client expects no answer to its request with Token=0, so it
> sends out a new request with Token=0, but server does not recognize
> No-Response option, and sends a response, then the client receives the
> old delayed response with
> define 'patience' in CoAP, but an implementer would still need to make
> a sane choice here.) Can we argue that Patience i.e. max response
> delay will be "a few minutes" and hence Token can be re-used safely
> after a time far longer than that, say 15 minutes?
>
> If several people in the CoRE WG saw it wrong, it may be worth
> pointing out as well to a non-CoRE audience ;)
>
> Esko
>
> I was pointing out that a request that is defined in such a way that
> it MAY elicit a response (depending on some condition unknown to the
> client at the
> response it does not know whether it can retire the token or still has
> to expect a response for that.
>
> Now if the client does not care about whether any response coming back
> is related back to the right request, it can reuse tokens at liberty.
> (Including the zero-length token, which is in no way special, except
> that it is indeed shorter than any other token.)
>
> Most clients will have a "patience" up to which they will expect a
> response, but we currently do not expose this at the protocol level.
> (With some new option, the client could pose a deadline to the server,
> or the server could promise a deadline to the client.
> 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, 23 Apr 2014 06:43:19 +0000

Indeed, a short summary of attention points would be good in my view. And we can avoid stating specific timing values.

Esko

From: Abhijan Bhattacharyya [mailto:[email-masked]]
Sent: Tuesday, April 22, 2014 21:43
To: Dijk, Esko
Cc: [email-masked]
Subject: RE: [core] Handling tokens for No-response

Hi Esko,

Regards
Abhijan Bhattacharyya
Associate Consultant

-----"Dijk, Esko" <[email-masked]<mailto:[email-masked]>> wrote: -----
To: Abhijan Bhattacharyya <[email-masked]<mailto:[email-masked]>>
From: "Dijk, Esko" <[email-masked]<mailto:[email-masked]>>
Date: 04/22/2014 03:05PM
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [core] Handling tokens for No-response
Hello Abhijan,

Esko

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Dijk, Esko
Sent: Tuesday, April 22, 2014 08:53
To: Carsten Bormann; Abhijan Bhattacharyya
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [core] Handling tokens for No-response

Hi,

Esko

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Thursday, April 17, 2014 15:08
To: Abhijan Bhattacharyya
Cc: weigengyu; Dijk, Esko; Rahman, Akbar; [email-masked]<mailto:[email-masked]>
Subject: Re: [core] Handling tokens for No-response

Gr.AN|N_e, Carsten

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

---

From: "weigengyu" <[email-masked]>
Date: Wed, 23 Apr 2014 16:10:46 +0800

HI,

Thanks Kepeng and Esko for your answers.

If the token length is ZERO, then there is no token. So the token is empty.
If the token length is one, for example, the value of the token could be 
from 0 to 255.
   In this case, when the value of token is 0, the token is not empty.

As the sematics of Zero length token is defined in CoAP -18,
when No-Response is identified by Zeron length token, it can not get an 
effect.
It seems better to make No-Response explicit and clear.

And, "Token re-use strategy" is required for the implementation.
We name it as token significant time, token is regard as being used within 
this time interval.
But it is different from Patience, and is longer than Patience.

Regards,

Gengyu

-----原始邮件----- 
From: Dijk, Esko
Sent: Wednesday, April 23, 2014 1:33 PM
To: Likepeng ; weigengyu ; Abhijan Bhattacharyya
Cc: [email-masked]
Subject: RE: [core] Handling tokens for No-response

> In my understanding, "empty token value" means zero-length token.
Yes, this is specified in Section 3.2. - it defines "empty option value" and 
since Token is an option, empty Token is equal to a zero-length Token. And 
zero-length encodes the number 0 so that is the same thing as a Token with 
an explicit zero value put in.

Esko

-----Original Message-----
From: Likepeng [mailto:[email-masked]]
Sent: Wednesday, April 23, 2014 02:58
To: weigengyu; Dijk, Esko; Abhijan Bhattacharyya
Cc: [email-masked]
Subject: Re: [core] Handling tokens for No-response

Kind Regards
Kepeng

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 23 Apr 2014 10:22:35 +0200

> If the token length is ZERO, then there is no token. So the token is empty.

If the token length is zero, there still is a token, it is just of length zero.
There is nothing special about this token value; I have no idea why this is discussed as if it were.

> If the token length is one, for example, the value of the token could be from 0 to 255.

The token is an opaque byte string (for a one-byte token, the value of the first and only byte would indeed be between 0 and 255).

>  In this case, when the value of token is 0, the token is not empty.

Indeed, what you mean seems to be just another token value, a byte string of length 1 with a zero byte.

> As the sematics of Zero length token is defined in CoAP -18,

Zero length tokens do not have any special semantics as defined in the CoAP specification.

> when No-Response is identified by Zeron length token, it can not get an effect.

Non sequitur.

The discussion of how to choose token values, including when a previously used token can be used again, is quite relevant for a client implementation (and I would expect the LWIG document to gain some substance here in the next revision), but there is nothing special about the zero-length token value in this discussion.

Grüße, Carsten

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Wed, 23 Apr 2014 16:12:41 +0530

Hi Carsten,

> The discussion of how to choose token values, including when a 
> previously used token can be used again, is quite relevant for a 
> client implementation (and I would expect the LWIG document to gain 
> some substance here in the next revision)

If I have understood correctly, by LWIG document you are referring to the 
LWIG draft on CoAP implementation guidance. Possibly, it can have one more 
subsection "2.4.3. Tokens for No-Response/ unidirectional request" or 
something like that. The problem is, tokens are conceptualized with a 
matching criteria. Section 2.4 of draft-kovatsch-lwig-coap-03 reads: "This 
begins when being assigned to a request and ends when the open request is 
closed by receiving and matching the final response". Unidirectional 
requests basically deviates from this primary concept of token usage. And 
we would need to define some timing at the request/response layer if we 
have to give some specific direction in the draft.

Regards
Abhijan Bhattacharyya
Associate Consultant

Carsten Bormann <[email-masked]> wrote on 04/23/2014 01:52:35 PM:

> From:
> 
> Carsten Bormann <[email-masked]>
> 
> To:
> 
> weigengyu <[email-masked]>
> 
> Cc:
> 
> "Dijk, Esko" <[email-masked]>, Likepeng 
> <[email-masked]>, Abhijan Bhattacharyya 
> <[email-masked]>, [email-masked]
> 
> Date:
> 
> 04/23/2014 01:52 PM
> 
> Subject:
> 
> A number of clarifications about ?empty tokens":
> 
> The token is an opaque byte string (for a one-byte token, the value 
> of the first and only byte would indeed be between 0 and 255).
> 
> The discussion of how to choose token values, including when a 
> previously used token can be used again, is quite relevant for a 
> client implementation (and I would expect the LWIG document to gain 
> some substance here in the next revision), but there is nothing 
> special about the zero-length token value in this discussion.
> 
> Grüße, Carsten
>

---

From: "weigengyu" <[email-masked]>
Date: Wed, 23 Apr 2014 21:19:00 +0800

Hi,

I think the following sentence need being clarified:

In CoAP -18 page 34,
"The client SHOULD generate tokens in such a way that tokens currently
in use for a given source/destination endpoint pair are unique.
(Note that a client implementation can use the same token for any
request if it uses a different endpoint each time, e.g. a different
source port number.) An empty token value is appropriate e.g. when
no other tokens are in use to a destination, or when requests are
made serially per destination and receive piggy-backed responses.
There are however multiple possible implementation strategies to
fulfill this. "

By this, zero length token is a token, it can be used the same way as other 
tokens.
If the request is with zero token, the response should adopt the zero token 
too.

Angthing wrong?

Regards,

Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications.

-----原始邮件----- 
From: Carsten Bormann
Sent: Wednesday, April 23, 2014 4:22 PM
To: weigengyu
Cc: Dijk, Esko ; Likepeng ; Abhijan Bhattacharyya ; [email-masked]
Subject: Re: [core] Handling tokens for No-response

> If the token length is ZERO, then there is no token. So the token is 

If the token length is zero, there still is a token, it is just of length 
zero.
There is nothing special about this token value; I have no idea why this is 
discussed as if it were.

> If the token length is one, for example, the value of the token could be 

The token is an opaque byte string (for a one-byte token, the value of the 
first and only byte would indeed be between 0 and 255).

>  In this case, when the value of token is 0, the token is not empty.

Indeed, what you mean seems to be just another token value, a byte string of 
length 1 with a zero byte.

> As the sematics of Zero length token is defined in CoAP -18,

Zero length tokens do not have any special semantics as defined in the CoAP 
specification.

Non sequitur.

The discussion of how to choose token values, including when a previously 
used token can be used again, is quite relevant for a client implementation 
(and I would expect the LWIG document to gain some substance here in the 
next revision), but there is nothing special about the zero-length token 
value in this discussion.

Grüße, Carsten