Subject: [core] CoAP observe: tokens and lifetime

From: Brian Frank <[email-masked]>
Date: Sun, 13 Feb 2011 12:19:39 -0500

The new observe draft looks very well written and thought out.  But I would
like to re-iterate some of my concerns with the ability to implement this
design in a constrained device.

The main problem I see is that the overhead required to implement a single
subscription on a single resource is prohibitive to make this an effective
solution in constrained devices.  The current design requires at at least 12
bytes per subscription if you assume 8 bytes per token and 4 bytes per
lifetime.  Most likely you also have a pointer to some host/port entry and
the resource itself which is 2-4 bytes depending on the architecture.
 "Constrained device" is a somewhat subjective thing, but to me allocating
100-200 bytes for subscription tables would seems pretty reasonable in
devices with under 100KB of total RAM memory.  With 12-20 bytes overhead per
subscriptions we are talking about only supporting a dozen or so
subscriptions in ~200 bytes.  With that limitation, I think most people
(including myself) would end up not using CoAP observe, and instead roll
their own custom solution that gave them more subscriptions with less
overhead.

The fundamental problem is that the design puts all the decisions in the
client's hand.  The client chooses the token size and the lifetime.  This
requires the server to pre-allocate the full 12 bytes to store a
token/lifetime (assuming most constrained devices are not going to be able
to handle dynamic memory allocation).

Let's first consider the token.  If I was designing a constrained device for
CoAP, then I one of my top priorities would be to design a URI namespace
with extremely short URIs.  In most designs I can imagine, most of my URIs
would probably be 2-6 bytes in length.  So using the URI would probably
always be smaller than the max 8 bytes of a token.  And depending on your
software design, the URI is probably alway known per resource so requires no
extra overhead.

The current design has a couple of assumptions around using tokens versus
URIs to match up notifications.  But does the token really buy us that much
considering its huge overhead? The proposed design requires clients to
generate new tokens to detect out of ordering messaging - that would require
some alternate mechanism to fix.  Maybe just have the server include some
"count" or "timestamp" option in each notification message.  So I would
propose to use URI instead of token for matching up notifications.

Next let's consider the lifetime overhead.  The current design lets the
client choose a unique lifetime per subscription.  Simple and elegant from a
spec perspective.  But from a pragmatic perspective, it isn't actually very
useful.  In my experience, most subscriptions tend to be:
  a) permanent machine-to-machine bindings (like switch to actuator) - they
will use biggest lifetime available
  b) user interface program which subscribes to data while "screen" is
active , then immediately unsubscribe (won't know lifetime in advance).
In either case, giving the client the flexibility to choose its subscription
lifetime with second granularity really doesn't buy us much considering the
trade-off we pay in overhead.

Here is what I would propose to solve the lifetime problem: give the server
the final say in lifetime, not the client. The client can suggest a
lifetime, but it would only be a hint.  Right now the spec explicitly only
gives servers the ability to make a lifetime shorter, not longer.  If the
server is given final say in the lifetime, then it can choose to maintain a
lifetime per client, rather than per subscription which would drastically
decrease the overhead per subscription.  And from an implementation
perspective, managing lifetimes per client is actually easy than per
subscription.  If a client fails to respond to a single acked notification,
then I would desire the spec to let me cancel all that client's
subscriptions (which would most likely indicate a communication path
failure).

So to recap:

Problem:
Too many bytes of overhead per subscription in current design.  I would like
to see a design where I could use a single bit per client to indicate a
subscription.

Proposed Solution:
  a) don't require servers to store token for each subscription; instead use
URI in each notification for matching up subscriptions client-side

  b) lifetime specified by client is just a suggestion or hint, final say in
subscription lifetime is determined by sever

Brian

---

From: Gilbert Clark <[email-masked]>
Date: Sun, 13 Feb 2011 14:20:08 -0500

Hi Brian:

Section 5 of the core-observe-01 draft implies to me that the server  
already has the final say in subscription lifetime.

Relevant quote:

"In a response, the Lifetime Option indicates a lower bound (e.g., by
rounding down) for the remaining observation lifetime.  (Note that
the server can always choose to cut short the observation lifetime
before it echoes this lifetime back in a response.)"

--Gilbert Clark

On Sun, 13 Feb 2011 12:19:39 -0500, Brian Frank <[email-masked]>  
wrote:

> The new observe draft looks very well written and thought out.  But I  
> would like to re-iterate some of my concerns with the ability to  
> implement this design in a constrained device.
>
> The main problem I see is that the overhead required to implement a  
> single subscription on a single resource is prohibitive to make this an  
> effective solution in constrained devices.  The current design requires  
> at at least 12 bytes per subscription if you assume 8 bytes per token  
> and 4 bytes per lifetime.  Most likely you also have a pointer to some  
> host/port entry and the resource itself which is 2-4 bytes depending on  
> the architecture.  "Constrained device" is a somewhat subjective thing,  
> but to me allocating 100-200 bytes for subscription tables would seems  
> pretty reasonable in devices with under 100KB of total RAM memory.  With  
> 12-20 bytes overhead per subscriptions we are talking about only  
> supporting a dozen or so subscriptions in ~200 bytes.  With that  
> limitation, I think most people (including myself) would end up not  
> using CoAP observe, and instead roll their own custom solution that gave  
> them more subscriptions with less overhead.
>
> client's hand.  The client chooses the token size and the lifetime.   
> This requires the server to pre-allocate the full 12 bytes to store a  
> token/lifetime (assuming most constrained devices are not going to be  
> able to handle dynamic memory allocation).
>
> Let's first consider the token.  If I was designing a constrained device  
> for CoAP, then I one of my top priorities would be to design a URI  
> namespace with extremely short URIs.  In most designs I can imagine,  
> most of my URIs would probably be 2-6 bytes in length.  So using the URI  
> would probably always be smaller than the max 8 bytes of a token.  And  
> depending on your software design, the URI is probably alway known per  
> resource so requires no extra overhead.
>
> The current design has a couple of assumptions around using tokens  
> versus URIs to match up notifications.  But does the token really buy us  
> that much considering its huge overhead? The proposed design requires  
> clients to generate new tokens to detect out of ordering messaging -  
> that would require some alternate mechanism to fix.  Maybe just have the  
> server include some "count" or "timestamp" option in each notification  
> message.  So I would propose to use URI instead of token for matching up  
> notifications.
>
> client choose a unique lifetime per subscription.  Simple and elegant  
> from a spec perspective.  But from a pragmatic perspective, it isn't  
> actually very useful.  In my experience, most subscriptions tend to be:
>   a) permanent machine-to-machine bindings (like switch to actuator) -  
> they will use biggest lifetime available
> In either case, giving the client the flexibility to choose its  
> subscription lifetime with second granularity really doesn't buy us much  
> considering the trade-off we pay in overhead.
>
> Here is what I would propose to solve the lifetime problem: give the  
> server the final say in lifetime, not the client. The client can suggest  
> a lifetime, but it would only be a hint.  Right now the spec explicitly  
> only gives servers the ability to make a lifetime shorter, not longer.   
> If the server is given final say in the lifetime, then it can choose to  
> maintain a lifetime per client, rather than per subscription which would  
> drastically decrease the overhead per subscription.  And from an  
> implementation perspective, managing lifetimes per client is actually  
> easy than per subscription.  If a client fails to respond to a single  
> acked notification, then I would desire the spec to let me cancel all  
> that client's subscriptions (which would most likely indicate a  
> communication path failure).
>
> So to recap:
>
> Problem:
> Too many bytes of overhead per subscription in current design.  I would  
> like to see a design where I could use a single bit per client to  
> indicate a subscription.
>
> Proposed Solution:
>   a) don't require servers to store token for each subscription; instead  
> use URI in each notification for matching up subscriptions client-side
>
>   b) lifetime specified by client is just a suggestion or hint, final  
> say in subscription lifetime is determined by sever

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 13 Feb 2011 20:47:23 +0100

Brian,

thanks -- these are very useful considerations.

Quick question:

The per-observation overhead is currently dominated by the IP address.  Changing any of the other data structures won't change much in the general case.

(I'm quite sympathetic with using the URI instead of the token -- that was our original design, but it seems simpler to focus everything on the token.)

It appears to me you have a specific use case in mind where there are lots of observation relationships from a server to one client, so you seem to optimize for that.  Can you tell us more about that use case?

> If a client fails to respond to a single acked notification, then I would desire the spec to let me cancel all that client's subscriptions (which would most likely indicate a communication path failure).

That is indeed an interesting proposal.
(We would have to define in more details what a "client" is, depending on security modes etc.)

Gruesse, Carsten

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Sun, 13 Feb 2011 20:48:52 +0100

+1

On Sun, Feb 13, 2011 at 18:19, Brian Frank <[email-masked]> wrote:
> The client chooses the token size and the lifetime.  This requires the
> server to pre-allocate the full 12 bytes to store a token/lifetime (assuming
> most constrained devices are not going to be able to handle dynamic memory
> allocation).

---

From: Brian Frank <[email-masked]>
Date: Sun, 13 Feb 2011 19:16:58 -0500

Hi Carsten,

Regarding use cases, my primary use case has always been Sedona.  If you
aren't familiar with it, its open source so you can learn about it on the
web:

http://sedonadev.org/

More importantly Sedona is one example of a typical use case for most
building automation or industrial automation devices.  These devices are
typically generic devices with some complement of digital and/or analog I/O,
which are programmed in the field by domain experts using a graphical tool.
 The application in these devices ends up as an assembly of software
components or function blocks (industrial PLCs often used 1131 for their
model).  So the use case is to treat each component/function block as a
resource (sometimes the individual properties of these components).
 Control algorithms might wire up a sensor function block to a PID block and
then out an actuator function block.  Where large number of subscriptions
becomes critical is when the tool or a end user "graphic" requiring the data
is accessed by a user.

It is true that the IP address and port of a client dwarfs the overhead of a
token and/or lifetime duration.  But it would be extremely rare for 100
different clients each to have one subscription.  A more realistic scenerio
(at least in my experience) is 1-10 clients, where each client might have
dozens or even 100s of subscriptions.

In this scenario we have too big optimization strategies we can leverage:

First, we can allocate one table for client addresses.  Lets say we allocate
room to store 8 client addresses.  Then multiple subscriptions for the same
client can reference this table.  If we had a max of 8 concurrent clients,
then we really only need a bit per resource to keep track of what each
client is subscribed too.  We use a similar scheme already in Sedona over
6LoWPAN and it works extremely well.

The second major optimization is to realize that the most typical reason for
a subscription failure is a  network communication failure between the
server and client (network unplugged, the client is shutdown, rebooted,
etc).  If a single client with 100 subscriptions looses network
connectivity, it is much more efficient to recognize the entire client is
down versus each subscription.  So however the concept ends up in the spec,
I think it is important to note that failure to confirm a notification
message from a server to the client (or maybe after X failures), might
result in all subscriptions to that client being cancelled.  It would be
grossly inefficient to keep sending different notifications to the same down
client (from both a bandwidth perspective and the amount of time it takes to
reclaim precious memory in the subscription tables).

Hope that all makes sense.

Brian

On Sun, Feb 13, 2011 at 2:47 PM, Carsten Bormann <[email-masked]> wrote:

> The per-observation overhead is currently dominated by the IP address.
>  Changing any of the other data structures won't change much in the general
> case.
>
> (I'm quite sympathetic with using the URI instead of the token -- that was
> our original design, but it seems simpler to focus everything on the token.)
>
> It appears to me you have a specific use case in mind where there are lots
> of observation relationships from a server to one client, so you seem to
> optimize for that.  Can you tell us more about that use case?
>
> > If a client fails to respond to a single acked notification, then I would
> desire the spec to let me cancel all that client's subscriptions (which
> would most likely indicate a communication path failure).
>

---

From: "Stok, Peter van der" <[email-masked]>
Date: Mon, 14 Feb 2011 10:07:12 +0100

Dear all,

Reading the draft I do have two additional questions/remarks

-          Is a token unique per server, or is the token unique per client-server pair. That has an impact on the storage space per observation.

-          I regret that groups cannot subscribe. Having groups formed and identified with one url and and one IP address significantly reduces the storage space per observation. Non confirmed messages can be sent by the server. The server can check the identity of the group and check that the requester is part of the group.

Groups are the major reason for using the observer pattern for my type of applications,

Greetings,

Peter van der Stok

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Frank
Sent: Monday 14 February 2011 1:17
To: Carsten Bormann
Cc: [email-masked]
Subject: Re: [core] CoAP observe: tokens and lifetime

Hi Carsten,

Regarding use cases, my primary use case has always been Sedona.  If you aren't familiar with it, its open source so you can learn about it on the web:

http://sedonadev.org/

More importantly Sedona is one example of a typical use case for most building automation or industrial automation devices.  These devices are typically generic devices with some complement of digital and/or analog I/O, which are programmed in the field by domain experts using a graphical tool.  The application in these devices ends up as an assembly of software components or function blocks (industrial PLCs often used 1131 for their model).  So the use case is to treat each component/function block as a resource (sometimes the individual properties of these components).  Control algorithms might wire up a sensor function block to a PID block and then out an actuator function block.  Where large number of subscriptions becomes critical is when the tool or a end user "graphic" requiring the data is accessed by a user.

It is true that the IP address and port of a client dwarfs the overhead of a token and/or lifetime duration.  But it would be extremely rare for 100 different clients each to have one subscription.  A more realistic scenerio (at least in my experience) is 1-10 clients, where each client might have dozens or even 100s of subscriptions.

First, we can allocate one table for client addresses.  Lets say we allocate room to store 8 client addresses.  Then multiple subscriptions for the same client can reference this table.  If we had a max of 8 concurrent clients, then we really only need a bit per resource to keep track of what each client is subscribed too.  We use a similar scheme already in Sedona over 6LoWPAN and it works extremely well.

The second major optimization is to realize that the most typical reason for a subscription failure is a  network communication failure between the server and client (network unplugged, the client is shutdown, rebooted, etc).  If a single client with 100 subscriptions looses network connectivity, it is much more efficient to recognize the entire client is down versus each subscription.  So however the concept ends up in the spec, I think it is important to note that failure to confirm a notification message from a server to the client (or maybe after X failures), might result in all subscriptions to that client being cancelled.  It would be grossly inefficient to keep sending different notifications to the same down client (from both a bandwidth perspective and the amount of time it takes to reclaim precious memory in the subscription tables).

Brian

On Sun, Feb 13, 2011 at 2:47 PM, Carsten Bormann <[email-masked]<mailto:[email-masked]>> wrote:
Brian,

Quick question:

Gruesse, Carsten

________________________________
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: "Clark, Gilbert" <[email-masked]>
Date: Mon, 14 Feb 2011 18:47:27 -0500

What about allowing the client to logically subscribe to multiple resources by specifying the same token in OBSERVEs for multiple resources?  Thus, the token references a group of subscriptions rather than just one, and subscriptions could be invalidated in batches by invalidating the token.

Also, if other clients specified the same token ID in their subscription, they could hop into the same group as other subscribers.  Maybe an OBSERVE-CLONE with a token ID would subscribe an alternate client X to everything that Y was subscribed to or something (assuming X had appropriate privileges), with the caveat that X would also be using the same token as Y (so if X were unsubscribed, Y would be also).

--Gilbert Clark

On 2/13/11 7:16 PM, "Brian Frank" <[email-masked]> wrote:

Hi Carsten,

http://sedonadev.org/

Brian

Quick question:

Gruesse, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Wed, 16 Feb 2011 06:11:10 +0100

Brian,

I totally agree that for observations simply including the URI in the response would be a better solution. This was our original proposal as Carsten pointed out. When the WG converged on the Token solution for deferred, the assumption was this forced us to use the token solution also in observations. But does it? 

Proposal:

1. Include a default token in the first observation GET (do we allow a Token at all in this case?)
2. Default token is included in the first response to that GET
3. Subsequent notifications include the appropriate Uri-* components of the resource in question. 

> It is true that the IP address and port of a client dwarfs the overhead of a token and/or lifetime duration.  But it would be extremely rare for 100 different clients each to have one subscription.…

We have this same use case in e.g. AMI cases and other large-scale M2M deployments with centralized collection of data. 

> The second major optimization is to realize that the most typical reason for a subscription failure is a  network communication failure between the server and client (network unplugged, the client…

Yes, I agree this is a feature that is needed (regardless of the Token issue). 

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: Salvatore Loreto <[email-masked]>
Date: Wed, 16 Feb 2011 09:23:53 +0200

> before it echoes this lifetime back in a response.)"

Hi Gilbert,

I agree with Brian suggestion,
it would be much better if the servers have much freedom in decide the 
Lifetime of a subscription...
you are right, at moment the server has only the possibility to short 
the observation

but it would be easier for some servers forget about the duty to 
maintain the lifetime of different clients
and just reply that the subscription is forever
so leaving to the clients the task to cancel the subscription when they 
are not interested any more.

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Peter Bigot <[email-masked]>
Date: Wed, 16 Feb 2011 09:20:50 -0600

I would not say the assumption was we were forced to use token for
observation.  The argument, then as now, was that defining two distinct
mechanisms for correlating deferred REST responses with REST requests was
confusing and wasteful of space.

I had also objected to the unsupported claims that URI-based correlation was
simple and obvious, and asked for rules to be specified.  I see those are
now present in section 6.2 of CoAP-04.  They are fairly complex, including
RFC3986-based reference resolution and decoding pct-encoded characters.
memcmp(3) clearly won't do the job.

As far as I can tell, section 5.3 of CoAP-04 requires support for
Token-based correlation (if deferred responses are supported at all).  If
use of URI-based rather than Token-based correlation would require me to
implement the algorithm of section 6.2 on a constrained node when I
otherwise do not need it, it would make CoAP unusable on my 32KB ROM
devices.

In any case, to use URI-correlation for observation I believe section 6.3
needs to be updated to handle the case where the URI is present in the
header of a CoAP message that does not represent a REST request.  The rules
for inferring the Uri-Host and Uri-Port when absent are different in that
case, as it is the source not destination address and port that must be
extracted from the transport layer.  (In fact, support for reconstruction
then requires that the server sending a deferred response embed the correct
IP address and port for the resource as the transport-layer source address
for the CoAP message: a subtlety that should be called out.)

The URI-reconstruction process may also be underspecified when the
underlying transport packet is addressed to a multicast address.  I don't
believe this mechanism could be implemented on a POSIX socket platform
without extensions.

Peter

On Tue, Feb 15, 2011 at 11:11 PM, Zach Shelby <[email-masked]> wrote:

> Brian,
>
> I totally agree that for observations simply including the URI in the
> response would be a better solution. This was our original proposal as
> Carsten pointed out. When the WG converged on the Token solution for
> deferred, the assumption was this forced us to use the token solution also
> in observations. But does it?
>
> Proposal:
>
> > It is true that the IP address and port of a client dwarfs the overhead
> of a token and/or lifetime duration.  But it would be extremely rare for 100
> We have this same use case in e.g. AMI cases and other large-scale M2M
> deployments with centralized collection of data.
>
> >
> > First, we can allocate one table for client addresses.  Lets say we
> allocate room to store 8 client addresses.  Then multiple subscriptions for
> the same client can reference this table.  If we had a max of 8 concurrent
> clients, then we really only need a bit per resource to keep track of what
> each client is subscribed too.  We use a similar scheme already in Sedona
> over 6LoWPAN and it works extremely well.
> >
> > The second major optimization is to realize that the most typical reason
> for a subscription failure is a  network communication failure between the
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 16 Feb 2011 19:01:15 +0100

On Feb 16, 2011, at 16:20, Peter Bigot wrote:

> I had also objected to the unsupported claims that URI-based correlation was simple and obvious, and asked for rules to be specified.  I see those are now present in section 6.2 of CoAP-04.  They are fairly complex, including RFC3986-based reference resolution and decoding pct-encoded characters.  memcmp(3) clearly won't do the job.

Well, having to implement all of RFC 3986 in every node would certainly be a disaster.
That's why we are distilling the URI to its Uri-* components before sending it in the CoAP message.
So when we say "URI" correlation, we probably mean "Uri-*" correlation.
But the details would indeed need to be worked out if we want to go there -- Token saved us from that so far.

Gruesse, Carsten

---

From: Gilbert Clark <[email-masked]>
Date: Wed, 16 Feb 2011 14:40:49 -0500

Hi Sal:

Hit reply-to instead of reply-all.  Let's try this again!

Also, added a few things (below).

> are not interested any more.

Your (and Brian's) points make sense :)

I was thinking that, since the server seemed to be authoritative on  
subscription-lifetime, it could reply with a constant in that field to  
either extend a client's subscription or, in the extreme case, to keep it  
perpetually subscribed to a resource.  This solution isn't especially  
elegant, though, and "The server MUST NOT establish the relationship with  
a duration longer than requested" seems to mean a server couldn't legally  
do it.

If the subscription-lifetime were infinite, I think it might be good to  
explicitly state that notifications should occasionally be confirmable.

> /Sal

Best,
Gilbert

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 16 Feb 2011 20:52:30 +0100

On Feb 16, 2011, at 20:40, Gilbert Clark wrote:

> If the subscription-lifetime were infinite, I think it might be good to explicitly state that notifications should occasionally be confirmable.

observe-01 says:

   Note that the considerations about amplification attacks are somewhat
   amplified in an observation relationship.  In NoSec mode, a server
   MUST therefore strictly limit the number of messages generated from
   an observation relationship that it sends between receiving packets
   that confirm the actual interest of the recipient in the data; i.e.,
   any notifications sent in Non-Confirmable messages MUST be
   interspersed with Confirmable messages.  (An Attacker may still spoof
   the acknowledgements if the Confirmable messages are sufficiently
   predictable.)

Gruesse, Carsten

---

From: "Clark, Gilbert" <[email-masked]>
Date: Wed, 16 Feb 2011 15:09:49 -0500

So it does!  Thanks :)

--Gilbert

On 2/16/11 2:52 PM, "Carsten Bormann" <[email-masked]> wrote:

observe-01 says:

Gruesse, Carsten

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 17 Feb 2011 15:26:41 +0200

that was exactly my point,
the fact that notifications should occasionally be confirmable
should make really simple to offload the server from the need to manage 
life-time for the different subscriptions

/Sal

-- 
Salvatore Loreto
www.sloreto.com

On 2/16/11 10:09 PM, Clark, Gilbert wrote:
>     > If the subscription-lifetime were infinite, I think it might be
>     good to explicitly state that notifications should occasionally be
>     confirmable.
>
>     observe-01 says:
>

---

From: Brian Frank <[email-masked]>
Date: Fri, 18 Feb 2011 14:58:28 -0500

In practice I doubt a constrained device is going to do anything other than
byte-by-byte comparisons of the URI string.  Although in oBIX we had lots of
trouble with optional trailing slashes and whether we should use redirects
or other means to identify the canonical URI.

Maybe to keep it simple, we say that the server include the Uri-Path option
in the first response which defines the canonical URI being used by the
server.  Then the first response can be matched up by Token, get the
canonical URI, then subsequent notifications can do simple Uri-Path string
comparisons.

BTW, can some one explain the use case for deferred responses?  It doesn't
seem to solve the sleeping device use case (and I haven't seen much
discussion around that very important use case).

On Wed, Feb 16, 2011 at 1:01 PM, Carsten Bormann <[email-masked]> wrote:

> > I had also objected to the unsupported claims that URI-based correlation
> was simple and obvious, and asked for rules to be specified.  I see those
> are now present in section 6.2 of CoAP-04.  They are fairly complex,
> including RFC3986-based reference resolution and decoding pct-encoded
> characters.  memcmp(3) clearly won't do the job.
>

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 19 Feb 2011 10:44:33 +0100

On Feb 18, 2011, at 20:58, Brian Frank wrote:

> BTW, can some one explain the use case for deferred responses?  

I'd say the use case is the same as for immediate responses.
The latter are just an optimization (piggy-backing) that doesn't always apply:
If e.g. a sensor needs more than (RESPONSE_TIMEOUT - expected_soft_upper_bound_to_latency) to generate data, the server sends an (empty) ACK immediately and then uses a deferred response later.
This is one instance of what Henning Schulzrinne calls the action-reaction pattern.

Gruesse, Carsten

---

From: Peter Bigot <[email-masked]>
Date: Sat, 19 Feb 2011 07:26:48 -0600

Certainly one can view immediate responses as an optimization of deferred
response, but historically I don't remember it as evolving from that
perspective.  If it had, I would have expected the whole process of
correlating REST responses with requests to have been far more clearly
defined than it is even to this day (token? uri? luck?)

I was not an author, so can't speak to what the original intention was, but
several months fairly active participation on the newsgroup last summer did
not leave me with the belief that what's now called deferred response was
the base form.  I still see core CoAP as being a non-deferred
request/response transaction mechanism using transaction ID for
correlation.  The transaction request and response were designed to carry
REST messages as payload.  In its simplest form, the transaction and REST
requests are in the same transport message, and the transaction and REST
responses are in the same transport message.  There was no need to worry
about correlation at the REST layer because it came for free with
correlation at the transaction layer.

That a transaction response may omit the REST response, thus causing a REST
response to be carried in a transaction request, actually makes things
significantly more complicated because the two layers are fairly tightly
coupled in CoAP (with the code field overlaid with meanings from each
layer).

I had understood the original motivation for asynchronous (now deferred)
response to be support for responses that could not be computed within the
transaction-imposed timeouts without inducing undesirable retransmissions
from the requester.  This was, of course, long before the concept of
observation evolved to provide an alternative solution to that problem.

It would be cleaner, perhaps, to invert the perspective and view deferred
response as a server-initiated observe subscription with automatic
expiration after the first response.  This would return the primary
communications model in CoAP to being non-deferred transactions, which are
much more clearly defined (though not simple, what with security, timeouts,
load management, handling mis-ordered/duplicate transmissions, etc., all of
which could use a little more attention).  (I don't know whether my plea to
allow clients to control whether servers were allowed to use deferred
responses survived, but if it did this model would simply use it to indicate
whether a client was observe-capable, and the whole notion of deferred
responses gets subsumed into observation.)

Peter

On Sat, Feb 19, 2011 at 3:44 AM, Carsten Bormann <[email-masked]> wrote:

> If e.g. a sensor needs more than (RESPONSE_TIMEOUT -
> expected_soft_upper_bound_to_latency) to generate data, the server sends an
> (empty) ACK immediately and then uses a deferred response later.

---

From: Brian Frank <[email-masked]>
Date: Sat, 19 Feb 2011 09:35:49 -0500

Just to bring some clarity to what I would define as the use cases:

a)  the device has local I/O wired to sensors/actuators.  In this use case
the device will be scanning the I/O pretty much as fast as possible, often
to perform local PID control.  In this scenario, the deferred response use
case doesn't make sense because the most current value will always be
available.

b) the device has remote networked I/O or "mounts" resources from a remote
device.  In this scenario deferred response makes sense because we often
don't want to read/subscribe to a down-stream point/device until we really
need to.  In old non-IP systems this is scenario is a mess, but in COAP with
everything IP we can clean it up using proxies. If someone made a request to
coap:://O/sensor through proxy coap:://P, then it would make sense for P to
sometimes return a deferred response until it refreshed its cache

c) battery powered/sleeping devices would not always be scanning their
sensors since they would be trying to converse the battery as long as
possible.  However, these devices would mostly likely be sleeping most of
the time, so you could rarely send them a request directly.  You would
almost always have to go through a proxy, in which case this scenario is
really the same as b.  However, I still don't think we have any verberge in
spec for how proxy and sleeping devices coordinate their cache refresh
(which is a critical feature IMO).

So my conclusion is that deferred responses is really specific to proxy
responses.  Maybe we can simplify something there?  To be honest, I dislike
the idea of having both deferred responses and observations.  Essentially
observations put client in control and deferred responses put server in
control.  Both are slightly different paradigms of async messaging and both
are going to be serious trouble to integrate with HTTP.  Seems better to
figure out one async messaging paradigm versus two.  And in the case of
async messaging, I think client initiation is better.

I like Peter's idea to make deferred responses just a special case of
observation with one notification.  Maybe we can just have say that you
immediately return a 202-like status code that resource isn't in available.
 In this case the client has to try against later or you switch to an
observation.  If we really think this is a proxy only use case, then the
client already knows it is going thru a proxy and should expect a 202
response.

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 19 Feb 2011 16:02:38 +0100

On Feb 19, 2011, at 14:26, Peter Bigot wrote:

> did not leave me with the belief that what's now called deferred response was the base form.  

Well, that is certainly one way to view the protocol -- a server can decide never to send them, so a minimal implementation does not need them.

One thing we have learned from SIP (learned HARD) is that coupling reliability sublayer timing to application sublayer timing is *not* a good idea.  (Essentially, SIP on UDP is all but deprecated at this point.)  The current design with both an immediate and a deferred form to relay the response is heeding that experience.

And, yes, there are sensors that do need time to respond to a request.  This is not just a proxy thing.  But the presence of intermediaries is certainly another good argument to not get tied up in the coupling of the timings.

I think we are getting stuck in a micro-optimization here.

Gruesse, Carsten

---

From: Peter Bigot <[email-masked]>
Date: Sat, 19 Feb 2011 10:01:06 -0600

Yes, considering deferred responses to be associated with proxies makes
sense from a conceptual model, even if it is the origin server that is
providing proxy-like behavior.  Note that in this case, as well as when
interacting with a reverse proxy for sleeping nodes or other multi-hop
paths, the client does not know to expect a 202 response.

I still think it's cleaner for a client to indicate (perhaps by including an
empty Token option) that it's willing to accept a deferred response (whether
as a one-shot subscription or a separate concept).  Without that, a server
may waste resources preparing and sending a response the client will not be
able to process.

See, among others, the threads including
http://www.ietf.org/mail-archive/web/core/current/msg00787.html and
especially http://www.ietf.org/mail-archive/web/core/current/msg01207.html,
which contain issues directly related to this topic and where the discussion
was left unresolved at least twice before.

On the other hand, I'm reminded that it's unproductive to try to focus
attention on things that seem fairly fundamental to the conceptual model
underlying CoAP, but that are dismissed as micro-optimizations.  I'd
forgotten the lessons learned from my past failures to communicate, which
are due in part to my being restricted to working group email as my sole
medium of involvement (it was a tertiary strategic interest for a company
that I no longer work for).

Carry on as you were.

Peter

---

From: Salvatore Loreto <[email-masked]>
Date: Sat, 19 Feb 2011 19:18:08 +0200

+1 for the Peter's idea to make deferred responses just a special case 
of observation with one notification.

having only one async messaging paradigm would also help to integrate 
with HTTP

I already expressed my concerns on the integration of deferred responses 
with HTTP:
http://www.ietf.org/mail-archive/web/core/current/msg01511.html

the idea that the client can indicate that it's willing to accept a 
deferred response would really help the mapping.
Perhaps would be enough including "lifetime" without any value

cheers
Sal

On 2/19/11 6:01 PM, Peter Bigot wrote:
> Yes, considering deferred responses to be associated with proxies 
> makes sense from a conceptual model, even if it is the origin server 
> that is providing proxy-like behavior.  Note that in this case, as 
> well as when interacting with a reverse proxy for sleeping nodes or 
> other multi-hop paths, the client does not know to expect a 202 response.
>
> I still think it's cleaner for a client to indicate (perhaps by 
> including an empty Token option) that it's willing to accept a 
> deferred response (whether as a one-shot subscription or a separate 
> concept).  Without that, a server may waste resources preparing and 
> sending a response the client will not be able to process.
>
> especially 
> http://www.ietf.org/mail-archive/web/core/current/msg01207.html, which 
> contain issues directly related to this topic and where the discussion 
> attention on things that seem fairly fundamental to the conceptual 
> model underlying CoAP, but that are dismissed as micro-optimizations.  
> I'd forgotten the lessons learned from my past failures to 
> communicate, which are due in part to my being restricted to working 
> group email as my sole medium of involvement (it was a tertiary 
> strategic interest for a company that I no longer work for).
>
> Carry on as you were.
>
> Peter
>
> On Sat, Feb 19, 2011 at 8:35 AM, Brian Frank <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     a)  the device has local I/O wired to sensors/actuators.  In this
>     use case the device will be scanning the I/O pretty much as fast
>     as possible, often to perform local PID control.  In
>     this scenario, the deferred response use case doesn't make sense
>     because the most current value will always be available.
>
>     b) the device has remote networked I/O or "mounts" resources from
>     a remote device.  In this scenario deferred response makes sense
>     because we often don't want to read/subscribe to a down-stream
>     point/device until we really need to.  In old non-IP systems this
>     is scenario is a mess, but in COAP with everything IP we can clean
>     it up using proxies. If someone made a request to coap:://O/sensor
>     through proxy coap:://P, then it would make sense for P to
>     c) battery powered/sleeping devices would not always be scanning
>     their sensors since they would be trying to converse the battery
>     as long as possible.  However, these devices would mostly likely
>     be sleeping most of the time, so you could rarely send them a
>     request directly.  You would almost always have to go through a
>     proxy, in which case this scenario is really the same as b.
>      However, I still don't think we have any verberge in spec for how
>     proxy and sleeping devices coordinate their cache refresh (which
>     is a critical feature IMO).
>
>     So my conclusion is that deferred responses is really specific to
>     proxy responses.  Maybe we can simplify something there?  To be
>     honest, I dislike the idea of having both deferred responses and
>     observations.  Essentially observations put client in control and
>     deferred responses put server in control.  Both are slightly
>     different paradigms of async messaging and both are going to be
>     serious trouble to integrate with HTTP.  Seems better to figure
>     out one async messaging paradigm versus two.  And in the case of
>     I like Peter's idea to make deferred responses just a special case
>     of observation with one notification.  Maybe we can just have say
>     that you immediately return a 202-like status code that resource
>     isn't in available.  In this case the client has to try against
>     later or you switch to an observation.  If we really think this is
>     a proxy only use case, then the client already knows it is going
>     thru a proxy and should expect a 202 response.
>
>
>     On Sat, Feb 19, 2011 at 4:44 AM, Carsten Bormann <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         expected_soft_upper_bound_to_latency) to generate data, the
>         server sends an (empty) ACK immediately and then uses a
>         deferred response later.

-- 
Salvatore Loreto
www.sloreto.com

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 19 Feb 2011 23:48:19 +0100

On Feb 19, 2011, at 18:18, Salvatore Loreto wrote:

> the idea that the client can indicate that it's willing to accept a deferred response 

Folks, I don't get it.
What is so hard about accepting deferred responses?

You need to
-- separate stopping the timer (message level, ACK) from accepting the response (request/response level, 2.00 OK),
-- do a second kind of matching (Token) in addition to the simple MID-based response matching,
-- react to the message level CON (by sending an ACK).

This is about five additional lines of code in total.
Please explain to me why a client would ever not be willing to do that.  I absolutely have no idea.

Gruesse, Carsten

---

From: Brian Frank <[email-masked]>
Date: Sat, 19 Feb 2011 21:26:53 -0500

In my mind there are two potential problems with deferred responses:

First, this sort of async messaging requires state and suffers from all the
memory overhead problems I detailed in my original post.  A very simple
constrained device might only have enough memory and buffer space for a few
req/res transactions and the application will have to be designed
accordingly.  If the server can decide willy nilly that it might not respond
for several seconds (or minutes), then those buffers are locked up and not
available for any more messaging.  I can imagine certain tricks that might
help, but deferred responses undoubtably complicate memory management and
the state machine of applications of constrained devices.

Most importantly, deferred responses do not map well to HTTP integration.  I
haven't seen much discussion around this issue, but depending on the
deferred response time, the original HTTP's TCP connection will timeout or
require some long polling scheme.  Observations are hard enough to map to
HTTP, but they are probably a necessary evil and since they are client
initiated I can imagine some nice solutions say with using WebSockets.  But
since deferred responses are server driven, they are going to cause problems
in HTTP gateways.  Perhaps you guys have some discussed some elegant
solution to how HTTP gateways would handle deferred responses?

Just to re-iterate my viewpoint: HTTP integration is the killer feature of
CoAP.  Without awesome, seamless HTTP integration, I fear CoAP will be just
another fieldbus protocol in a sea of fieldbus protocols.  I expect HTTP
will also be the only protocol most enterprise IT organizations will use for
networking between their back end systems and field devices.  IT
organizations hate opening up firewalls, and especially hate UDP protocols.
 So if there is a feature in CoAP that doesn't map easily and cleanly into
HTTP, I think it deserves some serious justification.  I can see the
justification for observations (grudgingly :-), but I am still having
trouble seeing the justification for deferred responses.

Brian

On Sat, Feb 19, 2011 at 5:48 PM, Carsten Bormann <[email-masked]> wrote:

> deferred response
> -- separate stopping the timer (message level, ACK) from accepting the
> response (request/response level, 2.00 OK),

---

From: Peter Bigot <[email-masked]>
Date: Sat, 19 Feb 2011 20:27:34 -0600

I had forgotten the conclusion from
http://www.ietf.org/mail-archive/web/core/current/msg01345.html, where by a
vote of two to one the working group determined that clients must support
deferred responses.

The reasons why a client might not want to do this were summarized in that
thread and apparently have never been convincing enough to lead anybody else
to agree with me.

Which leaves me as bewildered as my perspective leaves Carsten.

Never mind.

Peter

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 20 Feb 2011 16:17:20 +0200

On 2/20/11 4:26 AM, Brian Frank wrote:
...
> Most importantly, deferred responses do not map well to HTTP integration.
I fully agree!

>  I haven't seen much discussion around this issue, but depending on 
> the deferred response time, the original HTTP's TCP connection will 
> timeout or require some long polling scheme.

I raised the issue last month ( 
http://www.ietf.org/mail-archive/web/core/current/msg01511.html )
but I didn't get any answer!

>  Observations are hard enough to map to HTTP, but they are probably a 
> necessary evil and since they are client initiated I can imagine some 
> nice solutions say with using WebSockets.

WebSocket is a possibility, but long polling it is also possible if the 
client (both the HTTP client and the HTTP/CoAP gateway acting as client)
  is aware of the fact its request will take time to be provided

>  But since deferred responses are server driven, they are going to 
> cause problems in HTTP gateways.  Perhaps you guys have some discussed 
> some elegant solution to how HTTP gateways would handle deferred 
> responses?

perhaps, also in the case of deferred response WebSocket would be the 
easiest solution.
Another possibility could be to manage all the HTTP requests that arrive 
to the gateway as long-polling requests, and then threat the not 
deferred one as a special case.
Of course there are also other possible hacks that can be implemented,
but they will reduce the transparency of the gateway or make it not 
transparent at all

>
> Just to re-iterate my viewpoint: HTTP integration is the killer 
> feature of CoAP.  Without awesome, seamless HTTP integration, I fear 
> CoAP will be just another fieldbus protocol in a sea of fieldbus 
> protocols.

I would say that
a smooth, easy and possibly transparent HTTP integration is the killer 
feature of CoAP

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

>  I expect HTTP will also be the only protocol most enterprise IT 
> organizations will use for networking between their back end systems 
> and field devices.  IT organizations hate opening up firewalls, and 
> especially hate UDP protocols.  So if there is a feature in CoAP that 
> doesn't map easily and cleanly into HTTP, I think it deserves some 
> serious justification.  I can see the justification for 
> observations (grudgingly :-), but I am still having trouble seeing the 
> justification for deferred responses.
>
> Brian
>
>
> On Sat, Feb 19, 2011 at 5:48 PM, Carsten Bormann <[email-masked] 
>     -- separate stopping the timer (message level, ACK) from accepting
>     the response (request/response level, 2.00 OK),
>     [email-masked] <mailto:[email-masked]>

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 20 Feb 2011 16:28:24 +0200

again,
leaving to the client the possibility to indicate if it is willing or 
not to accept a deferred response
would be a good compromise

an alternative could that the client MUST support deferred response by 
default;
but it has the possibility to signal to the server it does not want a 
deferred response
when it does not make sense for it

/Sal

-- 
Salvatore Loreto
www.sloreto.com

On 2/20/11 4:27 AM, Peter Bigot wrote:
> http://www.ietf.org/mail-archive/web/core/current/msg01345.html, where 
> by a vote of two to one the working group determined that clients must 
> support deferred responses.
>
> The reasons why a client might not want to do this were summarized in 
> that thread and apparently have never been convincing enough to lead 
> anybody else to agree with me.
>
> On Sat, Feb 19, 2011 at 4:48 PM, Carsten Bormann <[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 20 Feb 2011 16:44:30 +0100

This is interesting, because it reminds us how important the names are we give to things.

"Deferred responses" are not there to give a serve license to "decide willy nilly that it might not respond for several seconds (or minutes),"; it already can do that with "immediate responses" (up to about a minute), with additional overhead at the sender and at the peril of decreased reliability.  The point is to decouple the message layer (retransmission) timer from the application layer timing.  "Deferred" may be a bad name because it sounds a lot like "license for laziness", a bit like why the military couldn't accept the term "disruption tolerant networking" :-).  Deferred responses are not more async than immediate responses (everything is async in UDP), they are just not piggy-backed on the reliability layer ACKs.  If we lose one of the two, we should lose the piggy-backing (just an optimization).

Let me put it this way: You don't have a guarantee of an "immediate" (english word) response, even if we only had "immediate responses" (coap-04 term).  On the other hand, "deferred responses" (coap-04 term) are great for "immediate" (english word) responses, if these can take more than about a second (i.e., RESPONSE_TIMEOUT - expected soft upper bound for latency).  We apparently need a different pair of terms for the piggy-backed carriage ("immediate response") and the separate carriage ("deferred response") of responses.

Either kind of response carriage maps perfectly to HTTP: As with CoAP, HTTP also does not constrain application timing in any way.
(As a separate observation, the latter is what makes long polling possible, although that is certainly a stretch with respect to HTTP semantics.)
There is a silent assumption in HTTP that the client wants an answer now, the same silent assumption applies to CoAP, and it is not heeded by long-polling.

We had a discussion about sending a deadline with a request; I'm not sure we found a good reason for including that, but I'm also not sure we finished that discussion.

There cannot be a way to map "observe" in a straightforward way to HTTP, because HTTP simply does not have direct support for this element of semantics.
The closest equivalent would be long polling, but there is no easy way to find out in HTTP whether the client wants the current state of the resource (or wants to validate it) or wants to wait for the next change.
But this may not be too relevant, because observe is already useful on the way back from a server to the first proxy, so it is not very important whether it can be exposed directly to the HTTP end -- at a minimum, it helps an HTTP-to-CoAP proxy to avoid translating (short) polling on the HTTP side to (short) polling on the CoAP side.

Gruesse, Carsten

On Feb 20, 2011, at 03:26, Brian Frank wrote:

> First, this sort of async messaging requires state and suffers from all the memory overhead problems I detailed in my original post.  A very simple constrained device might only have enough memory and buffer space for a few req/res transactions and the application will have to be designed accordingly.  If the server can decide willy nilly that it might not respond for several seconds (or minutes), then those buffers are locked up and not available for any more messaging.  I can imagine certain tricks that might help, but deferred responses undoubtably complicate memory management and the state machine of applications of constrained devices.
> 
> Most importantly, deferred responses do not map well to HTTP integration.  I haven't seen much discussion around this issue, but depending on the deferred response time, the original HTTP's TCP connection will timeout or require some long polling scheme.  Observations are hard enough to map to HTTP, but they are probably a necessary evil and since they are client initiated I can imagine some nice solutions say with using WebSockets.  But since deferred responses are server driven, they are going to cause problems in HTTP gateways.  Perhaps you guys have some discussed some elegant solution to how HTTP gateways would handle deferred responses?
> 
> Just to re-iterate my viewpoint: HTTP integration is the killer feature of CoAP.  Without awesome, seamless HTTP integration, I fear CoAP will be just another fieldbus protocol in a sea of fieldbus protocols.  I expect HTTP will also be the only protocol most enterprise IT organizations will use for networking between their back end systems and field devices.  IT organizations hate opening up firewalls, and especially hate UDP protocols.  So if there is a feature in CoAP that doesn't map easily and cleanly into HTTP, I think it deserves some serious justification.  I can see the justification for observations (grudgingly :-), but I am still having trouble seeing the justification for deferred responses.
> 
> Brian
> 
>

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 20 Feb 2011 18:40:14 +0200

> (As a separate observation, the latter is what makes long polling possible, although that is certainly a stretch with respect to HTTP semantics.)
well not so perfectly.
indeed HTTP is time constrained by timeouts in the proxy present within 
the path:
a proxy usually close an idle TCP connections after a given interval of 
time (i.e. RESPONSE TIMEOUT + epsilon ).
That make immediate response to map smoothly with HTTP,
where how to manage deferred responses needs more thoughts.

> There is a silent assumption in HTTP that the client wants an answer now, the same silent assumption applies to CoAP, and it is not heeded by long-polling.
long-polling keeps in account the fact that proxies along the path close 
the TCP connection,
and to smoothly  inter-operate with them the hanging request is answered 
by the sever after a safe amount of time even if there is no update,
"forcing" (so to say) the client to issue another request

-- 
Salvatore Loreto
www.sloreto.com

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 20 Feb 2011 18:21:53 +0100

On Feb 20, 2011, at 17:40, Salvatore Loreto wrote:

> indeed HTTP is time constrained by timeouts in the proxy present within the path:
> a proxy usually close an idle TCP connections after a given interval of time (i.e. RESPONSE TIMEOUT + epsilon ).

A TCP connection used for HTTP is not "idle" when the client is still waiting for a response.
(Many servers trigger a true idle timeout rather quickly, e.g. in Apache 2 the default value of KeepAliveTimeout is 5 seconds, see http://httpd.apache.org/docs/2.2/mod/core.html#keepalivetimeout -- we don't have that issue at all in CoAP because we don't have idle connections.)

Yes, proxies also have request timeouts, 504 and all.  But none of this invalidates what I was saying.
As they should, HTTP proxy timeouts are way larger than CoAP's RESPONSE_TIMEOUT.
Apache 2.2 has a default value of 5 minutes, http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxytimeout -- even though that is often reduced to the order of 2 minutes in distributions.

> where how to manage deferred responses needs more thoughts.

Which meaning of the terms are you talking about, the CoAP ones or the english ones?
Both CoAP-04 "immediate responses" and CoAP-04 "deferred responses" do integrate smoothly with HTTP.
What you are saying needs different semantics of "immediate" and "deferred".

> long-polling keeps in account the fact that proxies along the path close the TCP connection,
> and to smoothly  inter-operate with them the hanging request is answered by the sever after a safe amount of time even if there is no update,

Yes, that is one way of if doing it (I'm more used to the client sending another request when the first one times out, though).  
How is that relevant to the discussion here (except that this strategy would be another use case for CoAP "deferred responses")?

If you don't want servers to take a long time to respond to a request, don't have them take a long time to respond.
I.e., Don't Do That Then*)!
Warping the protocol so that it breaks on everything but very short response times is not the right way to ensure this.

                                 oOo

(At some point I'd like to go back to discussing the subject line of this thread.  
I'd really like to find a way to make -observe even more lightweight for servers.
1) Dropping the Lifetime value, and
2) giving the server license to drop all observation relationships to a client when one response times out,
sound like approaches that might help.  What else?)

Gruesse, Carsten

*) http://www.catb.org/jargon/html/D/Don-t-do-that-then-.html

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Tue, 22 Feb 2011 11:52:56 +0100

I am still in doubt about the convenience of allowing a client not to
accept deferred responses.

Allowing the client not to handle deferred responses, simplifies the
client (how much?) but makes more complex server design. In a
constrained M2M context this is not welcome..

On the other hand, allowing the server to respond in an unbounded time
to each request seems not convenient, especially for very constrained
clients, handling only a low number of CoAP sessions at a time (one?),
that in the meantime could be "locked" waiting for that response.

For this reasons, in some sense I am in agreement with Peter that
constrained clients should not be obliged to support deferred
responses, if the server can arbitrarily defer the response for an
unbounded time.

But in some other sense, I am in agreement with Carsten that points
out the retransmit related scope of the non-piggybacked ACK, and that
we cannot oblige a server or a resource to provide a response in the
"short" timeout of the CoAP retransmit timer because it will make too
complex server design for constrained devices.

I am not even sure if providing in some way (default, hard-coded,
option) a time limit for serving the request is the right way, because
that time limit can lead hardly manageable issues in the server.

Example: Is it simple to handle a POST/PUT/DELETE request with a time limit?

Moreover the HTTP mapping of this seems quite complex.

Best,
Angelo

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 22 Feb 2011 12:19:26 +0100

On Feb 22, 2011, at 11:52, Angelo P. Castellani wrote:

> allowing the server to respond in an unbounded time

HTTP is not putting up a constraint here, either.
How do clients handle that?

Gruesse, Carsten

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Tue, 22 Feb 2011 12:25:53 +0100

> How do clients handle that?

Regular clients usually (always?) support concurrency.

e.g.: browsers usually have multiple HTTP connections open when
downloading a bunch of HTTP resources (an HTTP page).

IMHO constrained clients may not have the same capabilities and may be
locked waiting for a "deferred" response.

Moreover, if in the meantime the server crashes or is rebooted, the
constrained node not supporting concurrency will be deadlocked (!!).

Best,
Angelo

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Tue, 22 Feb 2011 12:37:58 +0100

As an added lateral consideration, HTTP clients are also in some sense
the human users of the protocol.

They are supposed to timeout at some point when an HTTP resource is
not responding.

In order to realize a REST protocol for M2M communication, additional
considerations about this may be needed also in the protocol design.

A.

---

From: Zach Shelby <[email-masked]>
Date: Wed, 23 Feb 2011 17:15:28 +0200

Finally catching up here, sorry everyone, I have been on vacation.

> Warping the protocol so that it breaks on everything but very short response times is not the right way to ensure this.

After following most of the threads, it seems most of this "deferred response" issues is about:

- A misunderstanding about the word deferred, we are taking a time longer than RESPONSE_TIMEOUT but not minutes, hours or days. This was not meant to be used for very long polling.  
- People seem to assume that a client is forced to support deferred responses, or that a client *must* wait for a deferred response to come. That is not the case, a client may have its own timeout and can just stop waiting for the response. HTTP clients work in the same way, e.g. on your browser when it times out (or you timeout and hit the stop button...).
- There is also a misconception about how an HTTP proxy would work here. The CoAP transaction is transparent, if the proxy times out waiting for a response then it just does. The same thing can happen with an HTTP-HTTP proxy, so what? 

We could always drop deferred responses, but I don't think that would be very useful. Or we could only support observation for long responses, but that is only specified for GET. Especially with POST there will be cases where an operation related to a POST will take some time. 

Probably what we need to do is consider our timeouts related to responses in general. I have seen several other people come to a similar conclusion. Should there be some upper bound to a response delay before the server just doesn't bother any more? Should we specify a Response-Timeout option where the client specifies how long it will wait around for a response (if at all)? 

> I'd really like to find a way to make -observe even more lightweight for servers.

Agreed, that should be the priority here, although the timing issue with responses in general needs a sanity check.

> 1) Dropping the Lifetime value, and

Yep.

> sound like approaches that might help.  What else?)

I also like this.

Zach

---

From: Likepeng <[email-masked]>
Date: Sat, 26 Feb 2011 03:21:43 +0000

It seems that people have taken a rest on this thread. :)

>+1 for the Peter's idea to make deferred responses just a special case of observation with one notification.

Not sure about that. In my understanding, observation is mainly used for Get, but deferred responses can be used for all the operations, that is, Get/Put/Post/Delete.

Kind Regards
Kepeng
发件人: [email-masked] [mailto:[email-masked]] 代表 Salvatore Loreto
发送时间: 2011年2月20日 1:18
收件人: [email-masked]
主题: Re: [core] CoAP observe: tokens and lifetime

+1 for the Peter's idea to make deferred responses just a special case of observation with one notification.

having only one async messaging paradigm would also help to integrate with HTTP

I already expressed my concerns on the integration of deferred responses with HTTP:
http://www.ietf.org/mail-archive/web/core/current/msg01511.html

the idea that the client can indicate that it's willing to accept a deferred response would really help the mapping.
Perhaps would be enough including "lifetime" without any value

cheers
Sal

On 2/19/11 6:01 PM, Peter Bigot wrote:
Yes, considering deferred responses to be associated with proxies makes sense from a conceptual model, even if it is the origin server that is providing proxy-like behavior.  Note that in this case, as well as when interacting with a reverse proxy for sleeping nodes or other multi-hop paths, the client does not know to expect a 202 response.

I still think it's cleaner for a client to indicate (perhaps by including an empty Token option) that it's willing to accept a deferred response (whether as a one-shot subscription or a separate concept).  Without that, a server may waste resources preparing and sending a response the client will not be able to process.

See, among others, the threads including http://www.ietf.org/mail-archive/web/core/current/msg00787.html and especially http://www.ietf.org/mail-archive/web/core/current/msg01207.html, which contain issues directly related to this topic and where the discussion was left unresolved at least twice before.

On the other hand, I'm reminded that it's unproductive to try to focus attention on things that seem fairly fundamental to the conceptual model underlying CoAP, but that are dismissed as micro-optimizations.  I'd forgotten the lessons learned from my past failures to communicate, which are due in part to my being restricted to working group email as my sole medium of involvement (it was a tertiary strategic interest for a company that I no longer work for).

Carry on as you were.

Peter
On Sat, Feb 19, 2011 at 8:35 AM, Brian Frank <[email-masked]<mailto:[email-masked]>> wrote:
Just to bring some clarity to what I would define as the use cases:

a)  the device has local I/O wired to sensors/actuators.  In this use case the device will be scanning the I/O pretty much as fast as possible, often to perform local PID control.  In this scenario, the deferred response use case doesn't make sense because the most current value will always be available.

b) the device has remote networked I/O or "mounts" resources from a remote device.  In this scenario deferred response makes sense because we often don't want to read/subscribe to a down-stream point/device until we really need to.  In old non-IP systems this is scenario is a mess, but in COAP with everything IP we can clean it up using proxies. If someone made a request to coap:://O/sensor through proxy coap:://P, then it would make sense for P to sometimes return a deferred response until it refreshed its cache

c) battery powered/sleeping devices would not always be scanning their sensors since they would be trying to converse the battery as long as possible.  However, these devices would mostly likely be sleeping most of the time, so you could rarely send them a request directly.  You would almost always have to go through a proxy, in which case this scenario is really the same as b.  However, I still don't think we have any verberge in spec for how proxy and sleeping devices coordinate their cache refresh (which is a critical feature IMO).

So my conclusion is that deferred responses is really specific to proxy responses.  Maybe we can simplify something there?  To be honest, I dislike the idea of having both deferred responses and observations.  Essentially observations put client in control and deferred responses put server in control.  Both are slightly different paradigms of async messaging and both are going to be serious trouble to integrate with HTTP.  Seems better to figure out one async messaging paradigm versus two.  And in the case of async messaging, I think client initiation is better.

I like Peter's idea to make deferred responses just a special case of observation with one notification.  Maybe we can just have say that you immediately return a 202-like status code that resource isn't in available.  In this case the client has to try against later or you switch to an observation.  If we really think this is a proxy only use case, then the client already knows it is going thru a proxy and should expect a 202 response.

On Sat, Feb 19, 2011 at 4:44 AM, Carsten Bormann <[email-masked]<mailto:[email-masked]>> wrote:

Gruesse, Carsten

--

Salvatore Loreto

www.sloreto.com<http://www.sloreto.com>

---

From: Zach Shelby <[email-masked]>
Date: Mon, 28 Feb 2011 14:20:48 +0200

> Not sure about that. In my understanding, observation is mainly used for Get, but deferred responses can be used for all the operations, that is, Get/Put/Post/Delete.

You are correct, this is also why I believe we definitely need support for including responses on a new transaction message (what was called deferred response in coap-04, let's just call it a response). This is especially useful for any POST operation that might take more than RESPONSE_TIMEOUT to complete. This can easily happen when a sensor posts something to a busy M2M server for example. 

However I have suggested that we may need some maximum time that a server can wait before sending a response on a new transaction (this is not meant as a mechanism for long polling, just for sending responses that miss RESPONSE_TIMEOUT), in other words defining MAX_RESPONSE_TIME, which could be equivalent to the total time for performing the maximum number of retransmissions for example. 

Zach