Subject: [core] Resolution to tickets #176, #177, #181

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Feb 2012 16:23:23 +0100

Klaus and I sat together today and rearranged coap-misc, moving stuff that isn't ready for standardization to the appendices and finishing other stuff.

As a result, we are proposing the body of coap-misc as the resolution for tickets #176, #177 (and indirectly for #174), and #181, as well as the vendor-defined option that was discussed.

If these solutions are acceptable, this leaves us with #166 and #183 (#182 already has proposed text and just needs to be applied) on core-coap.  I also have to generate a proposal for #171 (block), and we need to decide whether #170 really needs any work.

I am optimistic we can finish all this in the next couple of days, so we have a set of documents that the authors believe is ready for WGLC.

Grüße, Carsten

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 16 Feb 2012 14:51:28 -0700

<hat type='individual'/>

On 2/15/12 8:23 AM, Carsten Bormann wrote:

> As a result, we are proposing the body of coap-misc as the resolution
> for tickets #176, #177 (and indirectly for #174), and #181, as well
> as the vendor-defined option that was discussed.

Regarding #181, would the proposed change obviate the need for the +exi
prefix as discussed on the apps-discuss list (since CoAP entities could
handle content-encoding)?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 16 Feb 2012 23:10:08 +0100

> handle content-encoding)?

I think that discussion is slightly confused (I haven't tried to  
intervene, as I'm not an EXI person).

application/foo+exi could be a media type for a schema-informed EXI  
encoding of foo+xml.
Content-Encoding is meant to be futzed with in proxies (all the 214  
verbage notwithstanding), so from my point of view needs to be  
schemaless.

But there are a lot of angels and pinheads in the interpretation of  
these attributes and concepts, so I think we need to be able to cope  
with both outcomes.

The Content-Encoding column is mainly an insurance against people  
claiming we need a Content-Encoding Option in CoAP because we can't  
have encoded media types.
HTTP wants media type and Content-Encoding to be orthogonal and freely  
combinable.
Since constrained devices are unlikely to have that level of  
orthogonality, I'd rather make it obvious that both media type and  
Content-Encoding are tied together in your decision of what to ship  
over the wireless.

If the "you can't have +exi but must encode that aspect of the  
representation format in Content-Encoding" faction wins, there will be  
zero change for us, except in the documents where we replace "+exi --"  
with "+xml exi" in some tables.

Protocol design 101: Design so you win with either possible outcome of  
a tussle.

Gruesse, Carsten

---

From: Li Shitao <[email-masked]>
Date: Fri, 17 Feb 2012 01:16:49 +0000

Hi all

I have submit a new draft about condition observe in CoAP, the main idea is using a new option called "condition" to carry the condition required by the observer.

In this draft, it has defined three condition type, the minimum response time, step and range. The detail usage has defined in this draft, if you are interested with this 

draft you can find it at http://datatracker.ietf.org/doc/draft-li-core-conditional-observe/ .

Hope to receive more comments!

regards
shitao

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Feb 2012 07:57:09 +0100

> draft you can find it at http://datatracker.ietf.org/doc/draft-li-core-conditional-observe/ .

I think that most applications will want to carry conditions like these in the URI, because ultimately there will be applications semantics that will trigger when a new resource state needs to be indicated.

Yes, it would be nice to separate the trigger condition from the resource identification (e.g., to improve caching), but it is hard to get such an architecture right.  Imagine a proxy that starts observation relationships with two clients, with different trigger conditions -- what trigger condition does it relay upstream to the origin server?  Ultimately, the proxy would need to understand enough of the application to combine the trigger conditions.  Proxies having to understand applications is a big no-no in our architecture.

Grüße, Carsten

---

From: Li Shitao <[email-masked]>
Date: Fri, 17 Feb 2012 07:29:28 +0000

Hi Carsten

Thanks for your reply!

But, I am not quite understanding about the proxy thing you mention here, as you said the proxy starts observation relationships with two clients, so they are two separate observation relationships, right? If they are, it can be distinguished by the message ID, the proxy can treat them as Different request. I did not see the problem here.

regards
Shitao

-----邮件原件-----
发件人: Carsten Bormann [mailto:[email-masked]] 
发送时间: 2012年2月17日 14:57
收件人: Li Shitao
抄送: [email-masked] WG
主题: Re: [core] New Version Notification for draft-li-core-conditional-observe-00.txt

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Feb 2012 08:37:47 +0100

> But, I am not quite understanding about the proxy thing you mention here, as you said the proxy starts observation relationships with two clients, so they are two separate observation relationships…

Right.

The problem is in the upstream observation relationship.  What trigger conditions does the proxy relay to the origin server?
If the triggers cannot be combined. there is no benefit the proxy can realize from both observation relationships using the same URI (i.e., no benefit from any separation of URI and trigger condition).

This is all theoretical, of course -- today's systems would model the trigger in the URI (most likely the query part), so there is nothing a proxy can do to combine multiple downstream observation relationships into one upstream.

BTW, I'd expect formats such as SenML to come up with conventions for how to specify such triggers.  JSON pointer comes to mind as a possible component.

Grüße, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Fri, 17 Feb 2012 10:17:19 +0200

> I think that most applications will want to carry conditions like these in the URI, because ultimately there will be applications semantics that will trigger when a new resource state needs to be i…

I agree. The newest version of the CoRE Interfaces draft includes such a URI based condition mechanism. 

http://tools.ietf.org/id/draft-shelby-core-interfaces-01.txt

Shitao, I am happy to hear your input if you think the conditions need some more improvement. These are meant to be simple conditions that can be used with any of the interface descriptions described in that draft. I do expect more complex conditions to be defined for specific market segments.

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
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: Li Shitao <[email-masked]>
Date: Fri, 17 Feb 2012 09:34:33 +0000

Related to the proxy combine. I got a question here, if the proxy receive two request both to the same URI, but one with the observe option, another not, if the proxy just do the URI check but no other option check,

When the proxy combine those two request together, what will be next? Forward which request to the server?

So to my understanding, the proxy at least need to analyze the observe option, right? Condition option as in my draft, should used together with the observe option, if the proxy can check the observe option, it is not hard to do one check about the condition option check.

The main reason, I found URI-query is not so good is, we use uri-query for many purposes, and most time we query some conditions that are not related to observe,  for a server, its logic needs to be quite complicated. But using a separate option to do this, can

simplify the logic of the CoAP server, it does not occupy more bits, but it save more resource on the server.

-----邮件原件-----

发送时间: 2012年2月17日 15:38

收件人: Li Shitao

抄送: [email-masked] WG

Right.

Grüße, Carsten

---

From: Jeroen Hoebeke <[email-masked]>
Date: Fri, 17 Feb 2012 11:37:00 +0100

> draft you can find it at http://datatracker.ietf.org/doc/draft-li-core-conditional-observe/ .

Dear Li, all

We are also looking into the possibility of using conditional observations. Based on earlier discussions on the list and the capabilities of the CoAP protocol, we saw three approaches for realizing conditional observations:

1) as a new option (in line with your proposal): compact bit-coding of frequently used conditional observations, the same coding can be used by a resource to announce how it can be observed (e.g. as part of .well-known/core) -> we are currently implementing such a solution in order to do some experiments. So we are definitely interested in your draft.

2) as part of the URI (as in CoRE Interfaces draft): here you could choose to use human-readable descriptions of the conditions or abbreviations in order to save bytes. Using this approach, it is not completely clear how a resource will describe its observation capabilities (assuming not all resources will implement the same conditional observations). You could for example retrieve the capabilities by making a request using a specific URI query. This approach is very flexible, but maybe too flexibly if a good agreed set of conditional observations is absent.

3) through the use of additional resources where you could both retrieve the possible conditional observations and establish the relationship: here the description could use semantics 

One can define many possible conditional observations, but we feel one will always have frequently occurring conditional observations (such as thresholds, frequency, variability…). Having an agreed specification for such a set could be very useful: e.g. to enable resources to announce how they can be observed, to achieve intelligent/automated processing of conditional observations, code reuse for implementing this on embedded devices...   

Jeroen

-- 
Jeroen Hoebeke
Senior Researcher
IBBT - IBCN/UGent
http://www.ibbt.be
http://www.ibcn.intec.UGent.be

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 17 Feb 2012 13:31:08 +0200

On 2/17/12 11:34 AM, Li Shitao wrote:
>
> Related to the proxy combine. I got a question here, if the proxy 
> receive two request both to the same URI, but one with the observe 
> option, another not, if the proxy just do the URI check but no other 
> option check,
>
> So to my understanding, the proxy at least need to analyze the observe 
> option, right? Condition option as in my draft, should used together 
> with the observe option, if the proxy can check the observe option, it 
> is not hard to do one check about the condition option check.
>
Hi Li and Carsten

I don't understand the issue with the proxy,
the draft try to minimize the traffic on the client side so if a proxy 
starts observation relationships with two or more clients, each with 
different trigger condition
it can just a plain observation relationship with the upstream (the 
origin) server. It is not necessary (and I do not thing I would like) 
for the proxy to combine or
do any strange or complicate operation before sending it to the origin 
server.
Of course I would expect the proxy filtering the observation to the 
downstream client based on the right Condition.

Having said that,
I am not sure I am convinced of the opportunity of having a Condition 
Option:
in a clean Restful architecture everything should be done in a Restful 
way (i.e. uri-query for the specific scenario);
however we have already deviated from the Restful clean architecture 
several time and actually the Observe scenario is one of them,
so if there is really the need for that (a Condition Option) ... why not,
but at moment I don't see it

-- 
Salvatore Loreto
www.sloreto.com

> The main reason, I found URI-query is not so good is, we use uri-query 
> for many purposes, and most time we query some conditions that are not 
> related to observe,  for a server, its logic needs to be quite 
> complicated. But using a separate option to do this, can
>

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 18 Feb 2012 10:29:19 +0100

> I don't understand the issue with the proxy,

I apologize for not making myself clear.
There is no issue.
Let's try again:

1) If you want to do trigger specifications now, you can put them in
   the URI.  So I don't personally see a need for urgent action.

1a) Trigger specs are by necessity somewhat application specific.  If
   you are interested in more standardization in this space, it is
   probably most productive to work within the framework of the
   application data formats of interest, such as SenML.

2) If we do not just want to standardize elements of a URI-based way
   of doing this, but want to pull down some of this functionality to
   the level of the CoAP protocol (e.g., in the form of a new CoAP
   Option), we should have a reason for that.

2a) One reason might be that we want to integrate better into the CoAP
   caching/proxying model.

2b) Problem statement:  Putting trigger specs in the URI means that a
   proxy that makes one resource upstream available to two clients
   downstream cannot make out this fact if the trigger specs are
   different.  E.g., a temp sensor that can provide data in regular
   intervals, one client that want a new temperature every minute and
   one that wants one every two minutes -- all the proxy sees are two
   different URIs; it therefore cannot combine its two downstream
   observation relationships into a single upstream one (here: once
   every minute).

2c) Again, a solution will need to tie in with application semantics,
   so doing 1a first will help us with doing 2 right.

So what I was arguing for was to put some energy first into looking
into trigger specs in the context of SenML or your favorite
application data format.

Grüße, Carsten

---

From: Salvatore Loreto <[email-masked]>
Date: Sat, 18 Feb 2012 15:36:40 +0200

as pointed out by Kepeng in
http://www.ietf.org/mail-archive/web/core/current/msg02644.html

we are working together to propose a solution for 174
that somehow overload the Patience Option
to clearly and cleanly solve  all the three different different case 
(Section 4.1 Patience, 4.2 Leisure, 4.3 Pledge you have at moment in 
coap-misc )

I don't see the need to define three different Options, but lets discuss 
it on the mailing list once the draft will be released
and eventually in one of the CoRe sessions in Paris.

The first version of the draft is almost ready and Li Kepeng will submit 
the draft in the next few days..

regards
Sal

-- 
Salvatore Loreto
www.sloreto.com

On 2/15/12 5:23 PM, Carsten Bormann wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Salvatore Loreto <[email-masked]>
Date: Sat, 18 Feb 2012 19:52:46 +0200

in line

>     the URI.  So I don't personally see a need for urgent action.
and I fully agree with you here!

>     of doing this,
"*to standardize* elements of a URI-based way"???
what do you mean, here?

>   but want to pull down some of this functionality to
agreed with you that at moment there are no clear use cases for this!

>     observation relationships into a single upstream one (here: once
maybe here, was my turn to not be able to explain myself clearly
for the use case you described in  2b I think that a possible and simple 
solution
would be for the proxy to simply do a single plain (or full if you 
prefer) relationship
  upstream and then apply the filtering stuff locally (in the 
proxy/cache)...

However this imply quite a lot of intelligence in the proxy, and I am 
not sure I like it.

> into trigger specs in the context of SenML or your favorite
agree that more investigation are necessary

cheers
Salvatore

-- 
Salvatore Loreto
www.sloreto.com

---

From: Li Shitao <[email-masked]>
Date: Mon, 20 Feb 2012 06:40:52 +0000

hi Carsten and all

please see my comments inline.

Shitao

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Carsten Bormann
发送时间: 2012年2月18日 17:29
收件人: Salvatore Loreto
抄送: [email-masked]
主题: Re: [core] 答复: New Version Notification for draft-li-core-conditional-observe-00.txt

[shitao] I agree, we can use SenML to deifne some more interested data formats for application usage.

[shitao]yes, so we can first define our interesting triggers (conditions), then we can see if a new option is needed or not.

[shitao]As I responded in a previous email, even we do proxying, the proxy needs to 
Know the observe option, it needs to distinguish a normal GET request with a request with
Observe. 
And I got a question here, in the coap-08 spec, either in caching nor proxying section, 
I did not find the related sentence about the combining procedure you described. Did I missed somewhere, 
If so, can you provide me some usefully information about this.

[shitao]I fully agree with you here.

Grüße, Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 23 Feb 2012 14:55:33 +0000

Hello Carsten, Klaus,

some discussion about the Patience and Leisure concepts would be good I think.

"To avoid response implosion, responses to multicast requests SHOULD
   be dithered within a Leisure period chosen by the server to fall
   between these two bounds."

I have some questions about the proposed bounds:

1- if no Patience option is present, or if a server does not recognize it, there is no de facto upper bound. Would be good to indicate what to do in such cases?
2- the upper bound can be calculated lower than the lower bound (e.g. lower bound 10 seconds, and patience option specifies 5 seconds value). Will the leisure range now become a single value i.e. 10 seconds?
3- Suppose a group of 20 devices all receives a CoAP multicast request at about the same time. Now each device waits at least the "lower bound" time before sending any response, e.g. 10 seconds. Why would all these devices first collectively wait for 10 seconds (while nothing happens in the network...) before being able to respond? I.e. why a lower bound at all.
4- To make the situation worse, take the previous case combined with a Patience Option value of 10 seconds or lower in the request which sets the upper bound. Will the entire group of devices now respond at about the same time t=10 sec. ?

regards,
Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Wednesday 15 February 2012 16:23
To: [email-masked] WG
Subject: [core] Resolution to tickets #176, #177, #181

Grüße, 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: Carsten Bormann <[email-masked]>
Date: Thu, 23 Feb 2012 16:15:17 +0100

Hi Esko,

these are good questions, and I don't pretend to have final answers to all of them.
But let's try DTSTTCPW to obtain a starting position.

> 1- if no Patience option is present, or if a server does not recognize it, there is no de facto upper bound. Would be good to indicate what to do in such cases?

Well, there is no upper bound for anything in this case, as with HTTP or many other TCP-based protocols.
Traditionally, clients have had timeouts chosen on a scale that is based on human patience, e.g. 60 to 180 seconds.
Another approach is not to have timeouts at all but to consider the incoming responses a stream of additional data, to each of which you react separately.
E.g., in an interactive discovery application, a new response would cause a new icon to come up on the screen, independent of timeouts.
Being somewhat reasonable with respect to Leisure in a server becomes a quality of implementation issue then.

> 2- the upper bound can be calculated lower than the lower bound (e.g. lower bound 10 seconds, and patience option specifies 5 seconds value). Will the leisure range now become a single value i.e. 1…

Well, if the CC-based bound does not allow everyone to respond within the patience interval without overloading a channel, then not everyone should respond.
I think that makes the answer to your question a Yes.
This allows the system to slide into a multi-anycast situation when the request is unrealistic.

> 3- Suppose a group of 20 devices all receives a CoAP multicast request at about the same time. Now each device waits at least the "lower bound" time before sending any response, e.g. 10 seconds. Wh…

Oh, the lower bound is a lower bound for the choice of the value of Leisure, not the minimum time a response may take.
Devices dither their response delay within [0..Leisure].
(I need to fix the text to be clear that Leisure is a single number representing a duration, not a specific interval in time.)
Note that the distribution of responses within [0..Leisure] will be skewed a bit by the actual processing time in some cases; I was assuming this effect could simply be ignored for most multicast requests.

> 4- To make the situation worse, take the previous case combined with a Patience Option value of 10 seconds or lower in the request which sets the upper bound. Will the entire group of devices now r…

No, see 3 above.

Grüße, Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 23 Feb 2012 16:03:02 +0000

Hi Carsten,

some comments below:

1-
I understand your reply that the client may have some predefined timeout/patience. Ok for me. I was wondering more about a server and the "SHOULD be dithered" recommendation. I can read it in two ways for a server: 1) if there's no upper bound I can ignore the SHOULD with good reason (i.e. no bound known!), or 2) the SHOULD still applies but I need to use a default/predefined upper bound. Or maybe an upper bound is not relevant anymore, because the server will anyway always apply dithering in the interval [0,lower-bound] ?  Or maybe the upper bound is still there and the server chooses Leisure between up/low bound depending on e.g. network traffic conditions.

2-
Given your answer to #3, this makes sense. So a server will dither in the interval [0,lower-bound] if ( upper-bound < lower-bound ).

3-
OK, clear, maybe text is then to be adapted: "...value that we will call Leisure, which indicates the period of time that will be used for responding to a request."  -> wrongly sounds like it will always take a time period "Leisure" before responding.

thanks
Esko

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Thursday 23 February 2012 16:15
To: Dijk, Esko
Cc: [email-masked] WG
Subject: Re: [core] Resolution to tickets #176, #177, #181

Hi Esko,

No, see 3 above.

Grüße, Carsten

---

From: Likepeng <[email-masked]>
Date: Mon, 27 Feb 2012 08:35:25 +0000

Hello all,

Here is the uploaded patience draft:
http://www.ietf.org/staging/draft-li-core-coap-patience-option-00.txt

Welcome your comments and feedbacks.

Thanks,
Kind Regards
Kepeng
发件人: [email-masked] [mailto:[email-masked]] 代表 Salvatore Loreto
发送时间: 2012年2月18日 21:37
收件人: [email-masked]
主题: [core] Patience ( was Re: Resolution to tickets #176, #177, #181)

we are working together to propose a solution for 174
that somehow overload the Patience Option
to clearly and cleanly solve  all the three different different case (Section 4.1 Patience, 4.2 Leisure, 4.3 Pledge you have at moment in coap-misc )

I don't see the need to define three different Options, but lets discuss it on the mailing list once the draft will be released
and eventually in one of the CoRe sessions in Paris.

The first version of the draft is almost ready and Li Kepeng will submit the draft in the next few days..

regards
Sal

--

Salvatore Loreto

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

Grüße, Carsten

core mailing list

[email-masked]<mailto:[email-masked]>