Subject: [core] section 2.1.2 Asynchronous response - a loss of CON message from the Server

From: "Koojana Kuladinithi" <[email-masked]>
Date: Thu, 21 Oct 2010 11:46:08 +0200

Hello,

I have started looking at draft-ietf-core-coap-02. When reading section
2.1.2 on Asynchronous response, the following was not clear to me.

In case of a loss of an asynchronous response (CON tid=783 ..message in
figure 3) from the server, who will take an action on retransmission?

1.  Does the server send the CON message with data again after some xx time?

2.  Does the client send GET message again after some xx time?     

For asynchronous transmission as explained in figure 3, can't we do as
follows?

1.  The client sends CON GET to the server without knowing whether syn/asyn
txs.

2.  The server sends ACK as in Figure 3, but with a Processing-Delay option
if the response gets delayed. (the experiments we did here show that to get
temperature/humidity results from an embedded device, it takes about ~300
ms). This Processing-Delay can be decided by the server based on the type of
URI. This lets the client to compute the waiting time to get the
asynchronous response. Example, Waiting-Time = (Processing-Delay +  RTT + xx
delay). 

If the client does not receive any delayed response from the server within
this Waiting-Time, the client should send again CON GET message. I believe
this would be a simple way to solve the above mentioned issues.

Kind regards

Koojana

Koojana Kuladinithi

University of Bremen, FB1 - IKOM/TZI

Otto-Hahn Allee NW1, 28359, Bremen, Germany 

Tel. +49 421 218 62382, Fax. +49 421 218 3601,

www: http://www.comnets.uni-bremen.de/~koo

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Oct 2010 14:50:20 +0200

> In case of a loss of an asynchronous response (CON tid=783 ..message in figure 3) from the server, who will take an action on retransmission?

Yes.

> For asynchronous transmission as explained in figure 3, can’t we do as follows?
> 1.  The client sends CON GET to the server without knowing whether syn/asyn txs.
> 2.  The server sends ACK as in Figure 3, but with a Processing-Delay option if the response gets delayed.
> (the experiments we did here show that to get temperature/humidity results from an embedded device, it takes about ~300 ms).

Interesting data point.  300 ms should be comfortably within the 500 ms default retransmission timeout, though, unless the wireless media is congested.

> This Processing-Delay can be decided by the server based on the type of URI. This lets the client to compute the waiting time to get the asynchronous response. Example, Waiting-Time = (Processing-Delay +  RTT + xx delay).
>  
> If the client does not receive any delayed response from the server within this Waiting-Time, the client should send again CON GET message. I believe this would be a simple way to solve the above mentioned issues.

This might work where the server has a deterministic processing delay.
A proxy may not be so lucky.  The result would be that we have a third kind of message exchange (one for immediate responses, one for deterministic responses, and one for non-deterministic responses).

Of course, at the REST level, a "try again in nnn ms" code might solve a similar problem.
Is the use case with a deterministic processing delay that does not fit in the default retransmission delay likely enough to warrant adding it?

Gruesse, Carsten

---

From: Peter Bigot <[email-masked]>
Date: Thu, 21 Oct 2010 08:29:37 -0500

As Carsten notes, the defined behavior is your option 1 (server retransmits
con response message).

I agree there is some uncertainty resulting from the asynchronous response
not having a time limit, and I too would rather have it resolved so I don't
have to hold onto request state in the client for an unbounded period, in
hopes that eventually my answer will come.

I read what you're suggesting as an elective header option, to be placed in
the ACK that indicates an asynchronous response, providing an upper bound on
how long the client should expect to wait for a response.

Further, we should give it a reasonable default.   31 seconds may elapse
between first CON transmission and last CON retransmission given the default
settings of MAX_RETRANSMIT and RESPONSE_TIMEOUT, at which point the server
will give up.  A default of 60 allows about 29 seconds for the server to
create the response representation before risking the client giving up too
soon.

Then a client that has not received the response after that time plus a
fudge term for network delays can assume the message is lost and recover in
whatever way is appropriate (e.g., retransmit the GET or give up).

I like this.

BTW: We did all realize that servers supporting asynchronous responses
should keep hold of the TID for the original request in the client response
record, so that if the server ACK gets lost and the client retransmits it
isn't interpreted as a new request, right?  I don't think I've seen that
called out explicitly anywhere.

Peter

On Thu, Oct 21, 2010 at 4:46 AM, Koojana Kuladinithi <
[email-masked]> wrote:

> 2.  The server sends ACK as in Figure 3, but with a Processing-Delay
> option if the response gets delayed. (the experiments we did here show that
> to get temperature/humidity results from an embedded device, it takes about
> ~300 ms). This Processing-Delay can be decided by the server based on the
> type of URI. This lets the client to compute the waiting time to get the
> www: http://www.comnets.uni-bremen.de/~koo<http://www.comnets.uni-bremen.de/%7Ekoo>
>
>
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Oct 2010 16:02:55 +0200

On Oct 21, 2010, at 15:29, Peter Bigot wrote:

> BTW: We did all realize that servers supporting asynchronous responses should keep hold of the TID for the original request in the client response record, so that if the server ACK gets lost and the client retransmits it isn't interpreted as a new request, right?  I don't think I've seen that called out explicitly anywhere.

I think keeping the TID for being able to do duplicate detection is a general rule for anything that is not both
-- idempotent (and cheap)
and
-- stateless.

Since the server needs to create (temporary) state to be able to send the async response later, it makes sense to include the TID in that state to combine any duplicates.

I think this is indeed an implementation consideration, but it may be worth a mention.
(More generally speaking, because many readers will be used to think in a strict transport/application layering, there are quite a number of things worth mentioning here.)

Gruesse, Carsten

---

From: Markus Becker <[email-masked]>
Date: Mon, 25 Oct 2010 11:48:50 +0200

> > figure 3) from the server, who will take an action on retransmission? 1.
> >  Does the server send the CON message with data again after some xx
> > time?
> 
> Yes.

It would be favorable if this would be clearly mentioned in the draft.

We see a problem with the current asynchronous operation if the server is 
retransmitting. If all asynchronous CON responses (even retransmitted ones) 
are lost, client behaviour is not defined. (Client has received ACK for CON 
request, but does not receive any CON response with data.) 

> > For asynchronous transmission as explained in figure 3, can’t we do as
> > follows? 1.  The client sends CON GET to the server without knowing
> > whether syn/asyn txs. 2.  The server sends ACK as in Figure 3, but with
> > a Processing-Delay option if the response gets delayed. (the experiments
> > we did here show that to get temperature/humidity results from an
> > embedded device, it takes about ~300 ms).
> 
> Interesting data point.  300 ms should be comfortably within the 500 ms
> default retransmission timeout, though, unless the wireless media is
> congested.

300 ms was for a rather simple temperature/humidity sensor. Other types of 
sensors might easily take more time, think accelaration sensor or video 
sensor.

You are mentioning 500 ms. In the draft it is meant to be 1s per default. Even 
with 1s, we experience retransmissions in our M2M scenario, which involves a 
GPRS link of 600ms to 1s RTT alone. Additionally, the 6lowpan implementation 
we are using exhibits a 100ms + ~10ms/hop RTT in non congested case.

> > This Processing-Delay can be decided by the server based on the type of
> > asynchronous response. Example, Waiting-Time = (Processing-Delay +  RTT
> > + xx delay).
> > 
> > If the client does not receive any delayed response from the server
> > within this Waiting-Time, the client should send again CON GET message.
> > I believe this would be a simple way to solve the above mentioned
> > issues.
> 
> A proxy may not be so lucky.  The result would be that we have a third kind
> of message exchange (one for immediate responses, one for deterministic
> responses, and one for non-deterministic responses).
> 
> Of course, at the REST level, a "try again in nnn ms" code might solve a
> similar problem. Is the use case with a deterministic processing delay
> that does not fit in the default retransmission delay likely enough to
> warrant adding it?

Based on above data points, we are thinking that it is not an uncommon case. 
Setting the retransmission parameters according to the link specifics is one 
option. Here we would have to set the value for the worst case (highest 
processing + transmission delay). 

By adding a delayed option in the async ACK, the client could dynamically 
adjust the waiting time for each resource.

> Gruesse, Carsten

Best regards,
Markus

------------------------------------------------
| Dipl.-Ing. Markus Becker
| Communication Networks
| Mobile Research Center
| TZI - Center for Computing Technologies
| University Bremen
| Germany
------------------------------------------------
| web: http://www.comnets.uni-bremen.de/~mab/
| mailto: [email-masked]
| telephone: +49 421 218 62379
| building: NW1 room: N2260
------------------------------------------------

---

From: Markus Becker <[email-masked]>
Date: Mon, 25 Oct 2010 11:50:21 +0200

> the ACK that indicates an asynchronous response, providing an upper bound
> on how long the client should expect to wait for a response.

An additional header option, yes. However, not sure about elective or 
critical. It needs to be elective option because it is in a ACK. (Can ACKs or 
RSTs include critical options at all?) It would however also need to be 
understood by all clients, because client behaviour after receiving the ACK is 
not yet defined properly ('request state for unbounded period').

> between first CON transmission and last CON retransmission given the
> default settings of MAX_RETRANSMIT and RESPONSE_TIMEOUT, at which point
> the server will give up.  A default of 60 allows about 29 seconds for the
> server to create the response representation before risking the client
> giving up too soon.
>

You are proposing the waiting time to be the processing time + time for 
retransmissions + network delays. What we suggested was the processing time + 
network delay of the response (without considering retransmissions of the 
server) and then let the client try the retransmission. We thought of this 
because of high delay links easily triggering unnecessary retransmissions.

> [email-masked]> wrote:
[snip]
> > option if the response gets delayed. (the experiments we did here show
> > that to get temperature/humidity results from an embedded device, it
> > takes about ~300 ms). This Processing-Delay can be decided by the server
> > based on the type of URI. This lets the client to compute the waiting
> > time to get the asynchronous response. Example, Waiting-Time =
> > (Processing-Delay +  RTT + xx delay).

> called out explicitly anywhere.

True.
 
Best regards,
Markus

> > www:
> > http://www.comnets.uni-bremen.de/~koo<http://www.comnets.uni-bremen.de/%
> > 7Ekoo>
> > 
> > 
> >

---

From: Peter Bigot <[email-masked]>
Date: Mon, 25 Oct 2010 07:41:15 -0500

You're right: I'd inappropriately included retransmissions when proposing a
default, somehow thinking that perhaps this delay was introduced or visible
at the REST layer.  While this could be done, it is more naturally cast as a
pseudo-REST or CoAP-layer concept, as is asynchronous responses, and
retransmissions are irrelevant.

The purpose of the default was to remove the undefined behavior in the base
document.  If the option description doesn't make the base document, a
default is unnecessary.  Similarly, the option might as well be elective in
that case, because system designers couldn't assume clients will implement
the option anyway and for usability a system must be robust in the presence
of clients that don't know how long they should wait (where "robust" should
not mean sending a critical option that may cause the client to fail its
request unnecessarily).

Question: I understand, maybe incorrectly, that there's a huge push to get
CoAP to RFC status ASAP, and that the WG's period-of-performance ends in
December.  Is there any chance for options and major changes that won't be
in coap-03 being added before CoAP becomes an RFC?  Or do we need to start
writing separate documents for this sort of thing?

Peter

On Mon, Oct 25, 2010 at 4:50 AM, Markus Becker <[email-masked]>wrote:

> > > http://www.comnets.uni-bremen.de/~koo<http://www.comnets.uni-bremen.de/%7Ekoo>
> <http://www.comnets.uni-bremen.de/%
> > > 7Ekoo>
> > >
> > >
> > >
> | web: http://www.comnets.uni-bremen.de/~mab/<http://www.comnets.uni-bremen.de/%7Emab/>

---

From: "Koojana Kuladinithi" <[email-masked]>
Date: Tue, 26 Oct 2010 22:02:15 +0200

Hello Zach,

As far as I understood, the client behavior of processing asynchronous
response (section 2.1.2) is not defined properly in the 03.txt version. We
had few email discussions on this issue (see the subject "section 2.1.2
Asynchronous response - a loss of CON message from the Server"). 

As Peter asked below, do you plan to address this in the current
specification?

Koojana

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peter Bigot
Sent: Monday, October 25, 2010 2:41 PM
To: Markus Becker
Cc: [email-masked]
Subject: Re: [core] section 2.1.2 Asynchronous response - a loss of CON
message from the Server

Peter

An additional header option, yes. However, not sure about elective or
critical. It needs to be elective option because it is in a ACK. (Can ACKs
or
RSTs include critical options at all?) It would however also need to be
understood by all clients, because client behaviour after receiving the ACK
is
not yet defined properly ('request state for unbounded period').

retransmissions + network delays. What we suggested was the processing time
+

[snip]

True.

Best regards,
Markus

> > http://www.comnets.uni-bremen.de/~koo
<http://www.comnets.uni-bremen.de/%7Ekoo>
<http://www.comnets.uni-bremen.de/% <http://www.comnets.uni-bremen.de/%25> 

<http://www.comnets.uni-bremen.de/%7Emab/>

---

From: Zach Shelby <[email-masked]>
Date: Wed, 27 Oct 2010 00:46:00 +0300

Hi Koojana,

This was left out on purpose for now, I think we need more WG discussion on the issue first. Will make a ticket on this to consider it for -04. 

And not totally related to this discussion: We start to have quite a few options, so anybody that suggests adding a new one, needs to figure out how to remove something else ;-)  OK, it is not that extreme, but we should remember that these are constrained devices, so at least mandatory features need to be minimized. In fact, I would say that going forward we need to spend our energy making CoAP even simpler than it is now rather than more complex. 

Zach

On Oct 26, 2010, at 11:02 PM, Koojana Kuladinithi wrote:

> Hello Zach,
>  
> As far as I understood, the client behavior of processing asynchronous response (section 2.1.2) is not defined properly in the 03.txt version. We had few email discussions on this issue (see the subject “section 2.1.2 Asynchronous response - a loss of CON message from the Server”).
>  
> As Peter asked below, do you plan to address this in the current specification?
>  
> Koojana
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Bigot
> Subject: Re: [core] section 2.1.2 Asynchronous response - a loss of CON message from the Server
>  
> You're right: I'd inappropriately included retransmissions when proposing a default, somehow thinking that perhaps this delay was introduced or visible at the REST layer.  While this could be done, it is more naturally cast as a pseudo-REST or CoAP-layer concept, as is asynchronous responses, and retransmissions are irrelevant.
> 
> The purpose of the default was to remove the undefined behavior in the base document.  If the option description doesn't make the base document, a default is unnecessary.  Similarly, the option might as well be elective in that case, because system designers couldn't assume clients will implement the option anyway and for usability a system must be robust in the presence of clients that don't know how long they should wait (where "robust" should not mean sending a critical option that may cause the client to fail its request unnecessarily).
> 
> Question: I understand, maybe incorrectly, that there's a huge push to get CoAP to RFC status ASAP, and that the WG's period-of-performance ends in December.  Is there any chance for options and major changes that won't be in coap-03 being added before CoAP becomes an RFC?  Or do we need to start writing separate documents for this sort of thing?
> 
> Peter
> 
> On Mon, Oct 25, 2010 at 4:50 AM, Markus Becker <[email-masked]> wrote:

-- 
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