Subject: Re: [core] Need WG input: request/response matching

From: Peter Bigot <[email-masked]>
Date: Wed, 1 Dec 2010 11:22:51 -0600

Time to wrap this up: Based on two "yes", one "no", and several dozen
abstaining, I think the consensus of the WG is that clients must support
deferred responses.  The rationale is an assumption that "constrained" is
loose enough that this is a not burden to any implementation.  An implicit
consequence is that there is no need for a client to be able to influence
the server's selection of immediate or deferred response.  The impact of
this on sleeping nodes is not a concern; presumably it can be handled by
proxies/reverse proxies.

This allows an entirely new conceptualization of CoAP transactions.  I had
thought of immediate response as the normal situation, with deferred a
special case to allow for long-duration operations.  With deferred response
support required, I can simplify my server by having it immediately transmit
a CoAP-layer acknowledgement of every request, and allow the REST layer to
provide the actual response at whatever time is most convenient.
Technically, given the previous consensus that the server is entitled to
change the contents of a CoAP-layer response to a retransmitted (same TID)
request, if the REST layer responds in time I still could bundle the
response into the ack in that situation.

Interesting.

Peter

On Sat, Nov 27, 2010 at 3:12 AM, Linyi Tian <[email-masked]> wrote:

>  Hi, Peter
>
>
>
> My answer is “yes”. Here is my observation:
>
> 1.       Client will not know whether the server needs time to process the
> request. It will be hard for client to decide when to use negotiation
> mechanism.
>
> 2.       The server chooses to use deferred message is because the server
> needs time to process the request. Even if the client wants to get the
> result immediately it may not be realistic. If the server can’t do it in
> ACK, what the server can do? Simply reject the message?
>
> 3.        If the end point can support the complex mechanism like
> scheduling, I can’t imagine it can’t store the state associated with Token
> for short of time.
>
>
>
> The main mechanism for the client needs is to store the Token and has a
> time-out mechanism. Maybe this is not a big issue for clients. Correct me if
> I am wrong.
>
>
>
> Cheers,
>
> Linyi
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Peter Bigot
> *Sent:* Friday, November 26, 2010 3:41 AM
> *To:* core
> *Subject:* [core] Need WG input: request/response matching
>
>
>
> After the telecon yesterday there is a remaining issue in
> http://trac.tools.ietf.org/wg/core/trac/ticket/74: whether or not CoAP
> must provide a mechanism, such as presence/absence of the Token option in a
> request, to influence the server's decision to use an immediate or deferred
> response to a specific request.
>
> Carsten and I hold opposing positions, and I don't know which side Zack
> ended on.  So, we really need group input on this:
>
> *Should clients be required to support deferred responses to their
> requests?*
>
>
> Carsten's position is "Yes", because this requirement has minimal impact on
> the client and so there is no need to provide such a mechanism.  Depending
> on the approach, this could reduce message sizes, simplify the client by
> eliminating the need to re-transmit a request with "deferred-ok" flag if the
> server can't send an immediate response, and simplify the server
> implementation.
>
> My position is "No".  While any end-point that can accept incoming requests
> should have this machinery, I believe extremely constrained clients might
> not want to incorporate that code (e.g., to send acknowledgements for
> incoming confirmable messages), or to support any sort of state associated
> with unfulfilled requests (e.g., correlating security contexts).  Further,
> even if a client has the mechanism in place, there may be temporary reasons
> why the client does not want a deferred response for a specific request.
> For example, following an observation by Zack, certain schedule-based access
> policies might be difficult to implement if deferred responses, as currently
> drafted, were allowed.  So, I think it's important to give the client the
> ability to prevent deferred responses.
>
> Carsten, please follow up if I've failed to explain your position
> adequately.
>
> Comments from anybody else?
>
> (This is a separate issue from a question of whether a client should be
> able to provide a deadline by which the server must provide either an
> immediate or deferred response, or to influence the retransmission delays
> e.g. due to use of a satellite link, although having a mechanism for these
> issues might make it a moot question.  I don't expect we'll have such a
> mechanism defined within the time by which we expect to submit CoAP to
> IESG.)
>
> Peter
>

---

From: Zach Shelby <[email-masked]>
Date: Thu, 2 Dec 2010 17:03:53 +0200

Peter,

Thanks for taking the poll on this. 

On Dec 1, 2010, at 7:22 PM, Peter Bigot wrote:

> Time to wrap this up: Based on two "yes", one "no", and several dozen abstaining, I think the consensus of the WG is that clients must support deferred responses.  The rationale is an assumption that "constrained" is loose enough that this is a not burden to any implementation.  An implicit consequence is that there is no need for a client to be able to influence the server's selection of immediate or deferred response.  The impact of this on sleeping nodes is not a concern; presumably it can be handled by proxies/reverse proxies.

In practice this means that a client makes a CON request, it must always includes a token. This token is always included in the corresponding response. Thus we never include the URI in a response for matching. I can live with that.

We have one more questions to answer for this ticket:

1. Do we allow the Token Option to have a default value, and thus not requiring a Token Option to be included for clients that perform one request at a time with an end-point? Klaus has this proposal in the ticket right now.

My personal opinion, is that we should consider supporting the default value, however the security risks of that need to considered carefully.

> 
> This allows an entirely new conceptualization of CoAP transactions.  I had thought of immediate response as the normal situation, with deferred a special case to allow for long-duration operations.  With deferred response support required, I can simplify my server by having it immediately transmit a CoAP-layer acknowledgement of every request, and allow the REST layer to provide the actual response at whatever time is most convenient.  Technically, given the previous consensus that the server is entitled to change the contents of a CoAP-layer response to a retransmitted (same TID) request, if the REST layer responds in time I still could bundle the response into the ack in that situation.

We are specifying how a protocol must behave here, not how clients are implemented. I do agree that there are interesting implementation optimizations to be made with this model. I am not sure that it would be wise or efficient to always immediately send an ACK, as you would increase network overhead, using 4 messages instead of 2. I think the recommendation is that the response SHOULD be included with the first ACK if possible in the specification.

Zach

> 1.       Client will not know whether the server needs time to process the request. It will be hard for client to decide when to use negotiation mechanism.
> 
> 2.       The server chooses to use deferred message is because the server needs time to process the request. Even if the client wants to get the result immediately it may not be realistic. If the server can’t do it in ACK, what the server can do? Simply reject the message?
> 
> 3.        If the end point can support the complex mechanism like scheduling, I can’t imagine it can’t store the state associated with Token for short of time.
> 
>  
> The main mechanism for the client needs is to store the Token and has a time-out mechanism. Maybe this is not a big issue for clients. Correct me if I am wrong.
> 
>  
> Cheers,
> 
> Linyi
> 
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Bigot
> Sent: Friday, November 26, 2010 3:41 AM
> To: core
> Subject: [core] Need WG input: request/response matching
> 
>  
> After the telecon yesterday there is a remaining issue in http://trac.tools.ietf.org/wg/core/trac/ticket/74: whether or not CoAP must provide a mechanism, such as presence/absence of the Token option in a request, to influence the server's decision to use an immediate or deferred response to a specific request.
> 
> Carsten and I hold opposing positions, and I don't know which side Zack ended on.  So, we really need group input on this:
> 
> Should clients be required to support deferred responses to their requests?
> 
> 
> Carsten's position is "Yes", because this requirement has minimal impact on the client and so there is no need to provide such a mechanism.  Depending on the approach, this could reduce message sizes, simplify the client by eliminating the need to re-transmit a request with "deferred-ok" flag if the server can't send an immediate response, and simplify the server implementation.
> 
> My position is "No".  While any end-point that can accept incoming requests should have this machinery, I believe extremely constrained clients might not want to incorporate that code (e.g., to send acknowledgements for incoming confirmable messages), or to support any sort of state associated with unfulfilled requests (e.g., correlating security contexts).  Further, even if a client has the mechanism in place, there may be temporary reasons why the client does not want a deferred response for a specific request.  For example, following an observation by Zack, certain schedule-based access policies might be difficult to implement if deferred responses, as currently drafted, were allowed.  So, I think it's important to give the client the ability to prevent deferred responses.
> 
> Carsten, please follow up if I've failed to explain your position adequately.
> 
> (This is a separate issue from a question of whether a client should be able to provide a deadline by which the server must provide either an immediate or deferred response, or to influence the retransmission delays e.g. due to use of a satellite link, although having a mechanism for these issues might make it a moot question.  I don't expect we'll have such a mechanism defined within the time by which we expect to submit CoAP to IESG.)
> 
> Peter
> 
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

-- 
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: Thu, 2 Dec 2010 16:23:44 +0100

On Dec 2, 2010, at 16:03, Zach Shelby wrote:

> We are specifying how a protocol must behave here, not how clients are implemented. 

Yes, but then we want to make sure we have a rough idea that (and thus to a certain extent how) clients *can* be implemented.

If the communication part of server is decoupled from the resource manager enough that it does not know whether the response will be ready in less than (RESPONSE_TIMEOUT - IP_latency_corrected_for_stddev), a likely implementation strategy is to set a timer (say, to 0.5 s) and to send the ACK/0 when the timer expires; if the response is ready before timer expiration, you cancel the timer and send an immediate response (ACK/response_code with options and payload).

Many highly constrained servers will be integrated enough that they can make the immediate/deferred decision in a much simpler way.

Re the token default: If a client only ever asks the same question to a specific server, a default value for the Token will serve that client well; more so if the exchange is protected by a security association.

Gruesse, Carsten