Subject: [core] CoAP 'infinite timeout' use case

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 26 Nov 2013 14:13:58 +0000

Dear all,

This is triggered by my previous message on sleepy nodes.
Does anyone know what could (should) be expected from a CoAP client implementation in the following use case:

-          Client C sends a CON request to server S;

-          S sends empty ACK to C

-          S starts processing to produce the request;

-          C receives ACK

-          S 'dies' (e.g. power failure, reset, crash...) before finalizing the response creation

-          C waits for a long time (and keeps waiting, the response never arrives - there is no CoAP standard timeout mechanism activated in this case)

Is there some sort of timeout behaviour expected of C? Or any interoperability guidelines on that?
(I see the CoAP plugtest test specs https://github.com/cabo/td-coap3 only address timeouts of "a couple of seconds")

Esko

________________________________
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: Carsten Bormann <[email-masked]>
Date: Tue, 26 Nov 2013 16:44:32 +0100

One general rule in CoAP is that timeouts are on the message layer, not on the request/response layer.

Most likely, there will still be a limit to the time in which the response is useful to the client.
E.g., in the HTTP world, many clients give up after ~ 60 seconds (even if the TCP connection below HTTP has longer timeouts).
But there is nothing in the HTTP spec that describes these timeouts.
I find it quite logical that CoAP hasn’t anything here either.
But maybe the analogy is not quite right, I’d like to hear about that.
(Klaus has a draft that would allow a client to even cancel an outstanding request, draft-hartke-core-coap-liveliness.)

Grüße, Carsten

PS.:

> (I see the CoAP plugtest test specs https://github.com/cabo/td-coap3 only address timeouts of “a couple of seconds”)

What specific test are are you referring here?
We didn’t test any client timeout for separate responses.

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 26 Nov 2013 16:03:17 +0000

Agree, I was somewhat expecting that CoAP would follow HTTP in this respect.
I did notice that for HTTP it is explicitly stated that no timeouts are needed but that they may (MAY?) be present; http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-25#section-6.5

I think the CoAP spec could at least makes a similar remark; currently it's not mentioned.

For implementers it's perhaps useful at some point to know what methods / best practices to use to detect the 'server dead' case; similar to the case for TCP of half-open connections and detection thereof where some approaches are documented. I assume for now it is timer-based with a custom timeout value, where the value must not be lower than MAX_LATENCY.

> We didn't test any client timeout for separate responses.
Oops, I didn't mean to say timeout here but time taken by the server for processing the request. It mentions " Some time (a couple of seconds) elapses." in the base.html test specs.
A similar case occurs when this "some time" is higher than the client's expectation of "some time" so that's even an aspect that could be tested. (E.g. use MAX_LATENCY instead of "couple of seconds"?)

Esko

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Tuesday, November 26, 2013 16:45
To: Dijk, Esko
Cc: core ([email-masked])
Subject: Re: [core] CoAP 'infinite timeout' use case

Most likely, there will still be a limit to the time in which the response is useful to the client.
E.g., in the HTTP world, many clients give up after ~ 60 seconds (even if the TCP connection below HTTP has longer timeouts).
But there is nothing in the HTTP spec that describes these timeouts.
I find it quite logical that CoAP hasn't anything here either.
But maybe the analogy is not quite right, I'd like to hear about that.
(Klaus has a draft that would allow a client to even cancel an outstanding request, draft-hartke-core-coap-liveliness.)

Grüße, Carsten

What specific test are are you referring here?
We didn't test any client timeout for separate responses.

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 26 Nov 2013 19:42:33 +0200

> E.g., in the HTTP world, many clients give up after ~ 60 seconds (even if the TCP connection below HTTP has longer timeouts).

It's worth keeping in mind that there might also be intermediaries
between the client and the origin server that may return a 5.04
(Gateway Timeout) response if they don't receive a response after some
timeout determined by their local configuration.

Esko Dijk wrote:
> For implementers it's perhaps useful at some point to know what methods / best practices to use to detect the 'server dead' case;

Currently there's only the "CoAP ping" that a client can send to
determine if a server is running at a given IP address/port number.
But that doesn't tell the client if it's the same server that the
client sent its request to, or if the server still plans to send a
response. For that you'd need something like
<http://tools.ietf.org/html/draft-hartke-core-coap-liveliness-00#section-2>.

Best regards,
Klaus

---

From: "weigengyu" <[email-masked]>
Date: Wed, 27 Nov 2013 12:19:04 +0800

Hi, Esko and Carsten,

I do not agree.
The original intention of HTTP is to download WEB page for personal reading.
But CoAP is for M2M control.

Request for control may require immediate or time-limited responses.
The message layer timesout is not enough for this.
CoAP should includes timeout at transaction sub-layer.

This may be the one of what CoAP is different from HTTP.

regards,

Gengyu

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

-----原始邮件----- 
From: Dijk, Esko
Sent: Wednesday, November 27, 2013 12:03 AM
To: Carsten Bormann
Cc: core ([email-masked])
Subject: Re: [core] CoAP 'infinite timeout' use case

Agree, I was somewhat expecting that CoAP would follow HTTP in this respect.
I did notice that for HTTP it is explicitly stated that no timeouts are 
needed but that they may (MAY?) be present; 
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-25#section-6.5

I think the CoAP spec could at least makes a similar remark; currently it's 
not mentioned.

For implementers it's perhaps useful at some point to know what methods / 
best practices to use to detect the 'server dead' case; similar to the case 
for TCP of half-open connections and detection thereof where some approaches 
are documented. I assume for now it is timer-based with a custom timeout 
value, where the value must not be lower than MAX_LATENCY.

> We didn't test any client timeout for separate responses.
Oops, I didn't mean to say timeout here but time taken by the server for 
processing the request. It mentions " Some time (a couple of seconds) 
elapses" in the base.html test specs.
A similar case occurs when this "some time" is higher than the client's 
expectation of "some time" so that's even an aspect that could be tested. 
(E.g use MAX_LATENCY instead of "couple of seconds"?)

Esko

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Tuesday, November 26, 2013 16:45
To: Dijk, Esko
Cc: core ([email-masked])
Subject: Re: [core] CoAP 'infinite timeout' use case

One general rule in CoAP is that timeouts are on the message layer, not on 
the request/response layer.

Most likely, there will still be a limit to the time in which the response 
is useful to the client.
E.g., in the HTTP world, many clients give up after ~ 60 seconds (even if 
the TCP connection below HTTP has longer timeouts).
But there is nothing in the HTTP spec that describes these timeouts.
I find it quite logical that CoAP hasn't anything here either.
But maybe the analogy is not quite right, I'd like to hear about that.
(Klaus has a draft that would allow a client to even cancel an outstanding 
request, draft-hartke-core-coap-liveliness.)

Grüße, Carsten

PS.:

> (I see the CoAP plugtest test specs https://github.com/cabo/td-coap3 only 
> address timeouts of "a couple of seconds")

________________________________
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: "Dijk, Esko" <[email-masked]>
Date: Wed, 27 Nov 2013 06:02:09 +0000

I don't see a problem for the immediate responses required for control applications. The server could/should then just respond immediately with the Piggy-backed response as hinted in section 5.2.1, and doing this the problem doesn't occur.

However, for separate responses (if the response generation takes longer than a few seconds) there are currently no standard mechanisms so the client would have to know beforehand approximately how long the server will take at most to process the request to a specific resource. I haven't encountered any practical problems with this yet except for use cases of request queuing by a CoAP proxy.

Esko

-----Original Message-----
From: weigengyu [mailto:[email-masked]] 
Sent: Wednesday, November 27, 2013 05:19
To: Dijk, Esko; Carsten Bormann
Cc: [email-masked]
Subject: Re: [core] CoAP 'infinite timeout' use case

Hi, Esko and Carsten,

I do not agree.

regards,

Gengyu

-----原始邮件-----
From: Dijk, Esko
Sent: Wednesday, November 27, 2013 12:03 AM
To: Carsten Bormann
Cc: core ([email-masked])
Subject: Re: [core] CoAP 'infinite timeout' use case

Agree, I was somewhat expecting that CoAP would follow HTTP in this respect.
I did notice that for HTTP it is explicitly stated that no timeouts are needed but that they may (MAY?) be present;
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-25#section-6.5

> We didn't test any client timeout for separate responses.
Oops, I didn't mean to say timeout here but time taken by the server for processing the request. It mentions " Some time (a couple of seconds) elapses" in the base.html test specs.
A similar case occurs when this "some time" is higher than the client's expectation of "some time" so that's even an aspect that could be tested. 
(E.g use MAX_LATENCY instead of "couple of seconds"?)

Esko

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Tuesday, November 26, 2013 16:45
To: Dijk, Esko
Cc: core ([email-masked])
Subject: Re: [core] CoAP 'infinite timeout' use case

Grüße, Carsten

PS.:

> (I see the CoAP plugtest test specs https://github.com/cabo/td-coap3 
> only address timeouts of "a couple of seconds")

---

From: "weigengyu" <[email-masked]>
Date: Wed, 27 Nov 2013 16:28:42 +0800

Hi, Esko,

When a client sends a request to turn off 10 lights by multicast,  immediate 
responses are expected.
When messages are send by unreliable multicast, it is undeterminded how long 
the client may wait.

Regards,

Gengyu

School of computer

-----原始邮件----- 
From: Dijk, Esko
Sent: Wednesday, November 27, 2013 2:02 PM
To: weigengyu ; Carsten Bormann
Cc: [email-masked]
Subject: RE: [core] CoAP 'infinite timeout' use case

I don't see a problem for the immediate responses required for control 
applications. The server could/should then just respond immediately with the 
Piggy-backed response as hinted in section 5.2.1, and doing this the problem 
doesn't occur.

However, for separate responses (if the response generation takes longer 
than a few seconds) there are currently no standard mechanisms so the client 
would have to know beforehand approximately how long the server will take at 
most to process the request to a specific resource. I haven't encountered 
any practical problems with this yet except for use cases of request queuing 
by a CoAP proxy.

Esko

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Wednesday, November 27, 2013 05:19
To: Dijk, Esko; Carsten Bormann
Cc: [email-masked]
Subject: Re: [core] CoAP 'infinite timeout' use case

Hi, Esko and Carsten,

I do not agree.

regards,

Gengyu

-----原始邮件-----
From: Dijk, Esko
Sent: Wednesday, November 27, 2013 12:03 AM
To: Carsten Bormann
Cc: core ([email-masked])
Subject: Re: [core] CoAP 'infinite timeout' use case

Esko

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Tuesday, November 26, 2013 16:45
To: Dijk, Esko
Cc: core ([email-masked])
Subject: Re: [core] CoAP 'infinite timeout' use case

Grüße, Carsten

---

From: Likepeng <[email-masked]>
Date: Wed, 27 Nov 2013 09:00:29 +0000

Hello Esko,

>However, for separate responses (if the response generation takes longer than a few seconds) there are currently no standard mechanisms so the client would have to know beforehand approximately how long the server will take at most to process the request to a specific resource.

Some time ago, we submitted a draft to propose a new Patience option for this:
http://tools.ietf.org/html/draft-li-core-coap-patience-option-02

I think it can solve the problem you mentioned.

Kind Regards
Kepeng

-----邮件原件-----
发件人: core [mailto:[email-masked]] 代表 Dijk, Esko
发送时间: 2013年11月27日 14:02
收件人: weigengyu; Carsten Bormann
抄送: [email-masked]
主题: Re: [core] CoAP 'infinite timeout' use case

Esko

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Wednesday, November 27, 2013 05:19
To: Dijk, Esko; Carsten Bormann
Cc: [email-masked]
Subject: Re: [core] CoAP 'infinite timeout' use case

Hi, Esko and Carsten,

I do not agree.

regards,

Gengyu

-----原始邮件-----
From: Dijk, Esko
Sent: Wednesday, November 27, 2013 12:03 AM
To: Carsten Bormann
Cc: core ([email-masked])
Subject: Re: [core] CoAP 'infinite timeout' use case

Esko

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Tuesday, November 26, 2013 16:45
To: Dijk, Esko
Cc: core ([email-masked])
Subject: Re: [core] CoAP 'infinite timeout' use case

Grüße, Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 27 Nov 2013 15:02:29 +0000

Hello Gengyu,

there are also cases where no response is expected, e.g. mentioned in http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-2.7 , any success responses are suppressed - no reporting back to the client at all. This works if the underlying IP multicast can be made "reliable enough", i.e. statistically reliable, which is achieved through MPL. And the client doesn't need to wait.
For the next groupcomm update I define reliable multicast as more stringent than that, namely the client would get confirmation of to which nodes the request could be delivered and to which not.

For the cases where the client wants to get responses back, it can just wait using an application-specific configured timeout (which may be based on knowledge about expected propagation time of a message through the network, etc.).

Esko

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Wednesday, November 27, 2013 09:29
To: Dijk, Esko; Carsten Bormann
Cc: [email-masked]
Subject: Re: [core] CoAP 'infinite timeout' use case

Hi, Esko,

When a client sends a request to turn off 10 lights by multicast,  immediate responses are expected.
When messages are send by unreliable multicast, it is undeterminded how long the client may wait.

Regards,

Gengyu

-----原始邮件-----
From: Dijk, Esko
Sent: Wednesday, November 27, 2013 2:02 PM
To: weigengyu ; Carsten Bormann
Cc: [email-masked]
Subject: RE: [core] CoAP 'infinite timeout' use case

Esko

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Wednesday, November 27, 2013 05:19
To: Dijk, Esko; Carsten Bormann
Cc: [email-masked]
Subject: Re: [core] CoAP 'infinite timeout' use case

Hi, Esko and Carsten,

I do not agree.

regards,

Gengyu

-----原始邮件-----
From: Dijk, Esko
Sent: Wednesday, November 27, 2013 12:03 AM
To: Carsten Bormann
Cc: core ([email-masked])
Subject: Re: [core] CoAP 'infinite timeout' use case

Esko

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Tuesday, November 26, 2013 16:45
To: Dijk, Esko
Cc: core ([email-masked])
Subject: Re: [core] CoAP 'infinite timeout' use case

Grüße, Carsten

---

From: "weigengyu" <[email-masked]>
Date: Thu, 28 Nov 2013 00:12:41 +0800

Hi Esko,

I agree that wether to have responses is determined by the application, the 
question is what CoAP chooses to support.

In the Internet area, as far as I know, IP layer protocols, including IP 
multicast, just do best effort.
The "reliable enough", i.e. statistically reliable, is actually unreliable.
The result of "And the client doesn't need to wait" is that "the alarming 
lights" are still on.

I am happy to see "For the next groupcomm update I define reliable multicast 
as more stringent than that."
In the Internet world, two alternatives are transport layer relialbe 
multicast or application reliable multicast.
I prefer the application layer reliable mulitcast.  And there may have some 
approaches to design the architecture.
We will also "put" our ideas after the CoAP charter appeals for reliable 
multicast.

The response delay is application requirements. The transaction sub-layer 
timesout is configured as applicaton-specific.
The message sub-layer reliability is essential for message delivery, but not 
enough for transactions.

Regards,

Gengyu

-----原始邮件----- 
From: Dijk, Esko
Sent: Wednesday, November 27, 2013 11:02 PM
To: weigengyu ; Carsten Bormann
Cc: [email-masked]
Subject: RE: [core] CoAP 'infinite timeout' use case

Hello Gengyu,

there are also cases where no response is expected, e.g. mentioned in 
http://tools.ietf.org/html/draft-ietf-core-groupcomm-16#section-2.7 , any 
success responses are suppressed - no reporting back to the client at all. 
This works if the underlying IP multicast can be made "reliable enough", 
i.e. statistically reliable, which is achieved through MPL. And the client 
doesn't need to wait.
For the next groupcomm update I define reliable multicast as more stringent 
than that, namely the client would get confirmation of to which nodes the 
request could be delivered and to which not.

For the cases where the client wants to get responses back, it can just wait 
using an application-specific configured timeout (which may be based on 
knowledge about expected propagation time of a message through the network, 
etc.).

Esko

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Wednesday, November 27, 2013 09:29
To: Dijk, Esko; Carsten Bormann
Cc: [email-masked]
Subject: Re: [core] CoAP 'infinite timeout' use case

Hi, Esko,

Regards,

Gengyu

-----原始邮件-----
From: Dijk, Esko
Sent: Wednesday, November 27, 2013 2:02 PM
To: weigengyu ; Carsten Bormann
Cc: [email-masked]
Subject: RE: [core] CoAP 'infinite timeout' use case

Esko

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Wednesday, November 27, 2013 05:19
To: Dijk, Esko; Carsten Bormann
Cc: [email-masked]
Subject: Re: [core] CoAP 'infinite timeout' use case

Hi, Esko and Carsten,

I do not agree.

regards,

Gengyu

-----原始邮件-----
From: Dijk, Esko
Sent: Wednesday, November 27, 2013 12:03 AM
To: Carsten Bormann
Cc: core ([email-masked])
Subject: Re: [core] CoAP 'infinite timeout' use case

Esko

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Tuesday, November 26, 2013 16:45
To: Dijk, Esko
Cc: core ([email-masked])
Subject: Re: [core] CoAP 'infinite timeout' use case

Grüße, Carsten