Subject: [core] draft-ietf-core-coap-06 Request Timeout

From: Cullen Jennings <[email-masked]>
Date: Mon, 9 May 2011 12:28:40 -0700

If a client sends a request such as a GET, what is the default timeout after which it should consider there was an error if it has not received a response?

Cullen <in my role as an individual contributor>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 9 May 2011 21:34:53 +0200

> If a client sends a request such as a GET, what is the default timeout after which it should consider there was an error if it has not received a response?

The same answer as for HTTP.
(There is no such defined value.)

Assuming that there were such a default value:
What should a server do when it is getting close to that value and still does not have an answer?
Since there is no good answer to that, I don't think there is a good reason to have such a default value.

Gruesse, Carsten

---

From: Likepeng <[email-masked]>
Date: Tue, 10 May 2011 01:17:32 +0000

I have a draft to let the client to define a timeout in the request:
http://tools.ietf.org/id/draft-li-core-coap-response-mode-option-00.txt

I think it is better than the default value.

I notice that in Hybi group, there is a similar proposal for HTTP:
http://www.ietf.org/id/draft-thomson-hybi-http-timeout-00.txt

I would like to get feedback from you on the draft.

Thanks,
Kind Regards
Kepeng
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Tuesday, May 10, 2011 3:35 AM
To: Cullen Jennings
Cc: core WG
Subject: Re: [core] draft-ietf-core-coap-06 Request Timeout

Gruesse, Carsten

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

---

From: Zach Shelby <[email-masked]>
Date: Tue, 10 May 2011 09:07:52 +0300

> Since there is no good answer to that, I don't think there is a good reason to have such a default value.

I agree, this is implementation specific.

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 10 May 2011 15:06:48 +0200

On May 10, 2011, at 03:17, Likepeng wrote:

> [...]

Sure.

1) Get rid of the P bit.
   Influencing this is none of the client's business.
   It is not even useful for a client -- since the option is elective, the client cannot even rely on it being heeded.
   There is no option in TCP to control whether the peer should send its data piggybacked on an ACK either.

2) I think I like the T part of the option.
   However, it should be rephrased as

	"indicates the length of time from the time of request the response would be useful for the client".

   Because that's all we can say.  If the server doesn't have the data, it doesn't have it.

   Representing T in exponential form sounds fine to me (but we have had some arguments on duration representation before).  I would deliberately keep the spec open on whether the base is milliseconds or 1024s of a second -- the clocks are not going to be that precise anyway, and this might help some implementations that count in 1024s ("mibiseconds") or in whole seconds.

3) T should not have a default value.

   (I'm not going to repeat why that would be a mistake, see my previous messages.)

4) We also need a new response code, "can't provide the data in time".

   This is a code that a server that already knows it won't be able to meet the deadline can send early on.
   (Note that the client cannot rely on getting the response code, because the server might have failed in the meantime.)

We haven't really discussed the difference between what is Connection-Timeout in draft-thomson-hybi-http-timeout-00 and this option, which is similar to Request-Timeout in that draft.

Gruesse, Carsten

---

From: Likepeng <[email-masked]>
Date: Wed, 11 May 2011 03:45:17 +0000

Thanks for the review.

The suggestions are quite reasonable. And I will include the changes in -01.

> We haven't really discussed the difference between what is Connection-Timeout in draft-thomson-hybi-http-timeout-00 and this option, which is similar to Request-Timeout in that draft.

I think it is not necessary to have Connection-Timeout in CoAP, because CoAP is based on UDP, and we don't need to maintain an idle connection.

Kind Regards
Kepeng
-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Tuesday, May 10, 2011 9:07 PM
To: Likepeng
Cc: Cullen Jennings; core WG
Subject: Re: [core] draft-ietf-core-coap-06 Request Timeout

Sure.

1) Get rid of the P bit.

Gruesse, Carsten