Subject: [core] Fw: New Version Notification for draft-li-core-coap-patience-option-03.txt

From: Likepeng <[email-masked]>
Date: Wed, 4 Dec 2013 07:32:50 +0000

Hello all,

This draft is related to the recent discussion about CoAP 'infinite timeout' use case.

Hope you can find some time to review it and give us feedback.

Thanks,
Kind Regards
Kepeng

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2013年12月4日 15:29
收件人: Likepeng; Bert Greevenbosch; Salvatore Loreto; Salvatore Loreto; Esko Dijk
主题: New Version Notification for draft-li-core-coap-patience-option-03.txt

A new version of I-D, draft-li-core-coap-patience-option-03.txt
has been successfully submitted by Kepeng Li and posted to the IETF repository.

Filename:	 draft-li-core-coap-patience-option
Revision:	 03
Title:		 CoAP Option Extension: Patience
Creation date:	 2013-12-04
Group:		 Individual Submission
Number of pages: 10
URL:             http://www.ietf.org/internet-drafts/draft-li-core-coap-patience-option-03.txt
Status:          http://datatracker.ietf.org/doc/draft-li-core-coap-patience-option
Htmlized:        http://tools.ietf.org/html/draft-li-core-coap-patience-option-03
Diff:            http://www.ietf.org/rfcdiff?url2=draft-li-core-coap-patience-option-03

Abstract:
   CoAP is a RESTful application protocol for constrained nodes and
   networks.  This specification provides a simple extension for CoAP,
   the Patience option.  This option informs a recipient of the
   preferred time frame for a request or response depending on usage
   context.  In a unicast request, it indicates the patience a client
   has in waiting for a response.  The CoAP server tries to return the
   response within the specified time frame.  In a multicast request, it
   indicates the patience a server should have in sending its response.
   The recipient would then try to randomly delay its response within
   the time frame that the requester indicated or computed by the
   recipient itself.  In a CoAP observe notification, it indicates the
   patience an observer should have in both waiting for a subsequent
   notification and in re-establishing an observation relation.

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

---

From: "weigengyu" <[email-masked]>
Date: Wed, 4 Dec 2013 10:24:03 -0500

Hi Kepeng,

After reading through the draft, I have a question.

By the Patience option the recipient of the message knows the Patience time 
of the requster and calculates the Leisure time.
The recipient should consider the RTT (round trip time )  between requester 
and recipient when doing calculation.

In order to facilitate the recipient's calculation, the requester could put 
a timestamp in the message.
The recipient would have the half transmission delays, and used as reference 
of the half of RTT.
Based on above description, the Leisure time equals to the Patience time - 
RTT.

I believe that the RTT needs to take care when the order of RTT and Patience 
time are near.
Maybe RTT calculation requires the same algorithms as TCP RTT calculation.

Regards,

Gengyu

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

-----原始邮件----- 
From: Likepeng
Sent: Wednesday, December 04, 2013 2:32 AM
To: [email-masked]
Subject: [core] Fw: New Version Notification for 
draft-li-core-coap-patience-option-03.txt

Hello all,

This draft is related to the recent discussion about CoAP 'infinite timeout' 
use case.

Thanks,
Kind Regards
Kepeng

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]]
发送时间: 2013年12月4日 15:29
收件人: Likepeng; Bert Greevenbosch; Salvatore Loreto; Salvatore Loreto; 
Esko Dijk

A new version of I-D, draft-li-core-coap-patience-option-03.txt
has been successfully submitted by Kepeng Li and posted to the IETF 
repository.

Filename: draft-li-core-coap-patience-option
Revision: 03
Title: CoAP Option Extension: Patience
Creation date: 2013-12-04
Group: Individual Submission
Number of pages: 10
URL: 
http://www.ietf.org/internet-drafts/draft-li-core-coap-patience-option-03.txt
Status: 
http://datatracker.ietf.org/doc/draft-li-core-coap-patience-option
Htmlized: 
http://tools.ietf.org/html/draft-li-core-coap-patience-option-03
Diff: 
http://www.ietf.org/rfcdiff?url2=draft-li-core-coap-patience-option-03

Abstract:

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

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

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 4 Dec 2013 16:54:05 +0100

Hi Gengyu,

> Maybe RTT calculation requires the same algorithms as TCP RTT calculation.

draft-bormann-core-cocoa proposes RTO/RTT estimation mechanisms for CoAP.
These mechanisms are partially based on the RFC 6298 algorithm.

Best regards,

Carles

> 主题: New Version Notification for

---

From: "weigengyu" <[email-masked]>
Date: Thu, 5 Dec 2013 08:49:36 +0800

Hi Carles,

The draft-bormann-core-cocoa is important and congestion is a big topic.
But I think the issue of congestion is the problem of message sublayer of 
CoAP.
In order to provide reliablity the message sublayer calculates RTT and RTO 
like TCP does.

But at the transaction sublayer, i.e the time between request and 
response(s),
there should be some kinds of timer control.

regards,

Gengyu

-----原始邮件----- 
From: Carles Gomez Montenegro
Sent: Wednesday, December 04, 2013 11:54 PM
To: weigengyu
Cc: [email-masked]
Subject: Re: [core] Fw: New Version Notification for 

Hi Gengyu,

Best regards,

Carles

> -----åŽŸå§‹é‚®ä»¶-----
> -----é‚®ä»¶åŽŸä»¶-----
> å‘ä»¶äºº: [email-masked] [mailto:[email-masked]]
> å‘é€æ—¶é—´: 2013å¹´12æœˆ4æ—¥ 15:29
> æ”¶ä»¶äºº: Likepeng; Bert Greevenbosch; Salvatore Loreto; Salvatore
> Loreto;
> Esko Dijk
> ä¸»é¢˜: New Version Notification for

---

From: Likepeng <[email-masked]>
Date: Thu, 5 Dec 2013 02:04:08 +0000

Hi Gengyu,

Thanks for reviewing the draft.

According to my experience from the previous IOP testing activities, usually the RTT will be less than 2 seconds. We performed several remote testing between China and Europe, also between China and US, RTT is less than 2 seconds. Also from the spec, ACK_TIMEOUT is 2 seconds. RTT should be less than that. 

I would assume that usually client should wait for the maximum transmission time expired before giving up. That means, Patience should be more than MAX_RETRANSMIT * ACK_TIMEOUT = 8 seconds. 

So, I can say, Patience is usually much longer than RTT. Basically patience is not necessarily to be that accurate. And we don't need to include the calculation algorithm for RTT in the Patience draft. But we can add some texts in the draft to say, when the client chooses the patience value, it should take the RTT into account.

Thanks,
Kind Regards
Kepeng

-----邮件原件-----
发件人: weigengyu [mailto:[email-masked]] 
发送时间: 2013年12月4日 23:24
收件人: Likepeng
抄送: [email-masked]
主题: Re: [core] Fw: New Version Notification for draft-li-core-coap-patience-option-03.txt

Hi Kepeng,

By the Patience option the recipient of the message knows the Patience time of the requster and calculates the Leisure time.
The recipient should consider the RTT (round trip time )  between requester and recipient when doing calculation.

In order to facilitate the recipient's calculation, the requester could put a timestamp in the message.
The recipient would have the half transmission delays, and used as reference of the half of RTT.
Based on above description, the Leisure time equals to the Patience time - RTT.

I believe that the RTT needs to take care when the order of RTT and Patience time are near.
Maybe RTT calculation requires the same algorithms as TCP RTT calculation.

Regards,

Gengyu

-----原始邮件-----
From: Likepeng
Sent: Wednesday, December 04, 2013 2:32 AM
To: [email-masked]
Subject: [core] Fw: New Version Notification for draft-li-core-coap-patience-option-03.txt

Hello all,

Thanks,
Kind Regards
Kepeng

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]]
发送时间: 2013年12月4日 15:29
收件人: Likepeng; Bert Greevenbosch; Salvatore Loreto; Salvatore Loreto; Esko Dijk
主题: New Version Notification for draft-li-core-coap-patience-option-03.txt

Abstract:

The IETF Secretariat

---

From: "weigengyu" <[email-masked]>
Date: Thu, 5 Dec 2013 11:12:51 +0800

Hi Kepeng, Carles and all,

According to CoAP architechture, there are message sbulayer and transaction 
sublayer.
As I understood, the congestion control is the message sublayer facility,
and Patience option is for the transaction sublayer, i.e. tolerance time 
delay of response.
Anything wrong?

Rtt could be measured at each sublayer. They might be different.
And it is easy to see that the RTT of Transaction sublayer should be larger 
than that of Message sublayer.

I have no data about RTT at transaction sublayer between a CoRE Endpoint and 
a host in Internet across seas and lands,
and wish the tested data can help to make default RTT.

We did a work serveral years ago, " Title: MLM: A monitoring system for 
network QoS based on multi-level measurement. "
Published in:  Broadband Network & Multimedia Technology, 2009. IC-BNMT '09. 
2nd IEEE International Conference.
Although it is different from CoAP, the characteristics on the layered 
protocals are understood.

Regards,

Gengyu
School of Computers

-----原始邮件----- 
From: Likepeng
Sent: Thursday, December 05, 2013 10:04 AM
To: weigengyu
Cc: [email-masked]
Subject: Re: [core] Fw: New Version Notification for 

Hi Gengyu,

According to my experience from the previous IOP testing activities, usually 
the RTT will be less than 2 seconds. We performed several remote testing 
between China and Europe, also between China and US, RTT is less than 2 
seconds. Also from the spec, ACK_TIMEOUT is 2 seconds. RTT should be less 
than that.

I would assume that usually client should wait for the maximum transmission 
time expired before giving up. That means, Patience should be more than 
MAX_RETRANSMIT * ACK_TIMEOUT = 8 seconds.

So, I can say, Patience is usually much longer than RTT. Basically patience 
is not necessarily to be that accurate. And we don't need to include the 
calculation algorithm for RTT in the Patience draft. But we can add some 
texts in the draft to say, when the client chooses the patience value, it 
should take the RTT into account.

Thanks,
Kind Regards
Kepeng

-----邮件原件-----
发件人: weigengyu [mailto:[email-masked]]
发送时间: 2013年12月4日 23:24
收件人: Likepeng
抄送: [email-masked]
主题: Re: [core] Fw: New Version Notification for 

Hi Kepeng,

Regards,

Gengyu

-----原始邮件-----
From: Likepeng
Sent: Wednesday, December 04, 2013 2:32 AM
To: [email-masked]
Subject: [core] Fw: New Version Notification for 

Hello all,

Thanks,
Kind Regards
Kepeng

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]]
发送时间: 2013年12月4日 15:29
收件人: Likepeng; Bert Greevenbosch; Salvatore Loreto; Salvatore Loreto; 
Esko Dijk

Abstract:

The IETF Secretariat

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 5 Dec 2013 08:01:11 +0100

On 04 Dec 2013, at 16:24, weigengyu <[email-masked]> wrote:

> the requester could put a timestamp in the message

If this is meant to be a timestamp in absolute time:

We cannot expect constrained nodes to have good realtime clocks.
So there is no way that a recipient could make direct use of an absolute time sent to it.

(Even relative measurements might be tenuous.
E.g., in -observe, we try to allow for total clock inaccuracies of up to -50/+100 %.
I would expect any Patience mechanism to be designed to similar tolerances.)

Grüße, Carsten

---

From: "weigengyu" <[email-masked]>
Date: Thu, 5 Dec 2013 16:28:30 +0800

Hi Carsten,

I am not sure whether all servers have the timer capabilty.
I have used the Sensor with Tiny OS for reseaching works, tiny os has rich 
timer functions.

>  So there is no way that a recipient could make direct use of an absolute 

Patience option tells how long the torlerance duration. Timestamp only 
informs when to start that duration.
If the constrained nodes do not have "good realtime clocks" and a recipient 
could not make direct use of an absolute time sent to it,
the reasonable process is to have the server a default value or just ignore 
it.

And If the server has timer capability, applications might define a 
mechanism to tune it when CoAP has not the facility.

> I would expect any Patience mechanism to be designed to similar 

I am interested in why "in -observe, we try to allow for total clock 
inaccuracies of up to -50/+100 %."

regards,

Gengyu

-----原始邮件----- 
From: Carsten Bormann
Sent: Thursday, December 05, 2013 3:01 PM
To: weigengyu
Cc: Likepeng ; core ([email-masked])
Subject: Re: [core] Fw: New Version Notification for 

We cannot expect constrained nodes to have good realtime clocks.
So there is no way that a recipient could make direct use of an absolute 
time sent to it.

(Even relative measurements might be tenuous.
E.g., in -observe, we try to allow for total clock inaccuracies of up 
to -50/+100 %.
I would expect any Patience mechanism to be designed to similar tolerances.)

Grüße, Carsten

---

From: "weigengyu" <[email-masked]>
Date: Thu, 5 Dec 2013 18:49:01 +0800

Hi Carsten,

If the number of constrained nodes which have not good realtime clock is 
large,
is it required to define a clock synchronization mechanism in CoAP?

I assume that such nodes should have a local timer, no matter good or bad,
the synchronization could help them to be near accurate.

regards,

Gengyu

-----原始邮件----- 
From: weigengyu
Sent: Thursday, December 05, 2013 4:28 PM
To: Carsten Bormann
Cc: [email-masked]
Subject: Re: [core] Fw: New Version Notification 
fordraft-li-core-coap-patience-option-03.txt

Hi Carsten,

regards,

Gengyu

-----原始邮件----- 
From: Carsten Bormann
Sent: Thursday, December 05, 2013 3:01 PM
To: weigengyu
Cc: Likepeng ; core ([email-masked])
Subject: Re: [core] Fw: New Version Notification for

Grüße, Carsten