Subject: Re: [core] Updates in core-groupcomm-19

From: Abhijan Bhattacharyya <[email-masked]>
Date: Wed, 2 Jul 2014 14:54:27 +0530

Hi Esko,
> 
> The Token value re-use guideline is an addition based on the 
> discussion thread “Handling tokens for No-response”, where this 
> issue was identified.
> For multicast the Token re-use time is now advised to be at least: 
>   NON_LIFETIME + MAX_LATENCY + MAX_SERVER_RESPONSE_DELAY
> which is in the order of several minutes. Note that there is no 
> limit on MAX_SERVER_RESPONSE_DELAY in the CoAP protocol, just like 
> in the HTTP case.
> 
Indeed. We have also mentioned similar suggestion in section 5.2 of 
http://tools.ietf.org/id/draft-tcs-coap-no-response-option-06.txt
to keep synergy. Irrespective of whether the client explicitly expresses 
disinterest in the response (using No-Response option) or the server 
decides on its own to suppress responses (as in multicast) the problem 
ultimately boils down to server's uncertainty in responding. 

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: Likepeng <[email-masked]>
Date: Fri, 4 Jul 2014 07:11:45 +0000

Hi,

>Irrespective of whether the client explicitly expresses disinterest in the response (using No-Response option) or the server decides on its own to suppress responses (as in multicast) the problem ultimately boils down to server's uncertainty in responding.

Another possibility for the server to suppress responses can be based on “Patience” option proposed in this draft:
http://datatracker.ietf.org/doc/draft-li-core-coap-patience-option/

If the server response time exceeds the “Patience” value specified in the client request, the server should suppress the response.

Kind Regards
Kepeng

发件人: core [mailto:[email-masked]] 代表 Abhijan Bhattacharyya
发送时间: 2014年7月2日 17:24
收件人: [email-masked]; [email-masked]
主题: Re: [core] Updates in core-groupcomm-19

Hi Esko,
> limit on MAX_SERVER_RESPONSE_DELAY in the CoAP protocol, just like
Indeed. We have also mentioned similar suggestion in section 5.2 of http://tools.ietf.org/id/draft-tcs-coap-no-response-option-06.txt
to keep synergy. Irrespective of whether the client explicitly expresses disinterest in the response (using No-Response option) or the server decides on its own to suppress responses (as in multicast) the problem ultimately boils down to server's uncertainty in responding.

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: Abhijan Bhattacharyya <[email-masked]>
Date: Fri, 4 Jul 2014 13:05:18 +0530

Hi Kepeng,
Yes, that is touched upon in Section 5.2 (Re-using Tokens) of 
http://tools.ietf.org/id/draft-tcs-coap-no-response-option-06.txt.
Here is some excerpt from the above mentioned section for ready reference:

"So the client implementation should implement an application
   specific 'patience' time till which it can re-use the token.
   Appendix-B.4.1 of [I-D.draft-bormann-coap-misc] defines 'patience'
   option which in effect puts a deadline to the server to respond
   back. However, 'patience' is not exposed to the protocol level at
   present. Hence, a reuse time for tokens is suggested with similar
   expression as in Section 2.5 of [I-D.ietf-core-groupcomm]:

   TOKEN_REUSE_TIME = NON_LIFETIME + MAX_SERVER_RESPONSE_DELAY +
   MAX_LATENCY.

   NON_LIFETIME and MAX_LATENCY are defined in 4.8.2 of [I-D.ietf-core-
   coap]. MAX_SERVER_RESPONSE_DELAY has same interpretation as in
   Section 2.5 of [I-D.ietf-core-groupcomm] for multicast request. But
   for unicast request MAX_SERVER_RESPONSE_DELAY is simply the expected
   maximum response delay from the server to which client sent the
   request. This delay includes the maximum Leisure time period as
   defined in Section 8.2 of [I-D.ietf-core-coap] and Appendix-B.4.2 of
   [I-D.draft-bormann-coap-misc]where group size (G) = 1 for unicast
   request."

Regards
Abhijan Bhattacharyya
Associate Consultant

Likepeng <[email-masked]> wrote on 07/04/2014 12:41:45 PM:

> From: Likepeng <[email-masked]>
> To: Abhijan Bhattacharyya <[email-masked]>, 
> "[email-masked]" <[email-masked]>, "[email-masked]" 
> <[email-masked]>
> Date: 07/04/2014 12:42 PM
> Subject: Re: [core] Updates in core-groupcomm-19
> 
> Hi,
> 
> >Irrespective of whether the client explicitly expresses disinterest
> in the response (using No-Response option) or the server decides on 
> its own to suppress responses (as in multicast) the problem 
> Another possibility for the server to suppress responses can be 
> based on “Patience” option proposed in this draft:
> If the server response time exceeds the “Patience” value specified 
> in the client request, the server should suppress the response.
> 
> Kind Regards
> Kepeng
> 
> to keep synergy. Irrespective of whether the client explicitly 
> expresses disinterest in the response (using No-Response option) or 
> the server decides on its own to suppress responses (as in 
> multicast) the problem ultimately boils down to server's uncertainty
> in responding. 
> 
> 
> Regards
> Abhijan Bhattacharyya
> Associate Consultant

---

From: Likepeng <[email-masked]>
Date: Fri, 4 Jul 2014 07:57:27 +0000

Hi Abhijan,

Thanks for pointing out.

>  So the client implementation should implement an application
>  back. However, 'patience' is not exposed to the protocol level at  present.

In this sense, it would be beneficial to standardize “Patience” option at the protocol level.

Kind Regards
Kepeng

发件人: Abhijan Bhattacharyya [mailto:[email-masked]]
发送时间: 2014年7月4日 15:35
收件人: Likepeng
抄送: [email-masked]; [email-masked]
主题: Re: [core] Updates in core-groupcomm-19

Hi Kepeng,
Yes, that is touched upon in Section 5.2 (Re-using Tokens) of http://tools.ietf.org/id/draft-tcs-coap-no-response-option-06.txt.
Here is some excerpt from the above mentioned section for ready reference:

Regards
Abhijan Bhattacharyya
Associate Consultant

Likepeng <[email-masked]<mailto:[email-masked]>> wrote on 07/04/2014 12:41:45 PM:

> From: Likepeng <[email-masked]<mailto:[email-masked]>>
> To: Abhijan Bhattacharyya <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>
> 收件人: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

---

From: "weigengyu" <[email-masked]>
Date: Fri, 4 Jul 2014 16:36:44 +0800

Hi all, 

> In this sense, it would be beneficial to standardize “Patience” option at the protocol level.

I  agree. 

And it will be beneficial to define some general token handling mechanisms 

based on characteristics of  request and response(s).

regards, 

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

From: Likepeng 
Sent: Friday, July 04, 2014 3:57 PM
To: Abhijan Bhattacharyya 
Cc: [email-masked] 
Subject: Re: [core] Updates in core-groupcomm-19

Hi Abhijan,

Thanks for pointing out.

Kind Regards

Kepeng

Hi Kepeng, 

Regards
Abhijan Bhattacharyya
Associate Consultant

Likepeng <[email-masked]> wrote on 07/04/2014 12:41:45 PM:

> To: Abhijan Bhattacharyya <mailto:[email-masked]>, 

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