Subject: Re: [core] WGLC for draft-ietf-core-link-format-02

From: Zach Shelby <[email-masked]>
Date: Tue, 1 Feb 2011 15:40:36 +0200

Peter,

Thanks again for the review, I now added most of these as tickets, so we should now have good ticket coverage for WGLC issues on link-format. I will start working on the update. 

Some comments on other issues in-line:

On Jan 26, 2011, at 1:14 AM, Peter Saint-Andre wrote:
> 
> 6. Do we have good examples of resources that would be hosted somewhere
> other than the constrained server (device) and how those would be used
> in CoRE? If so, we might provide those in Section 2.1.2.

Sure, not using the "hosted" relation necessarily, but other relations such as (this is already in the examples):

 <coap://www.example.com/sensors/temp123>;anchor="/sensors/temp"
   ;rel=describedby,

There is a use-case for a proxy hosting a resource directory that contains links to resources hosted on nodes in its constrained network, this is mentioned in the link-format document but the definition of how that works is left for future work, but such a link entry could look like:

</sensors/temp>; anchor="coap://sensor10.example.com"; rel="hosted"

> 
> 7. Section 2.1.3 states:
> 
>   It is not expected that all implementations will be able
>   to derive useful information from explicitly anchored links.
> 
> So how important is the feature? Is it useful in some kinds of
> implementations or deployments or environments but not others?

For the basic use case, describing resources hosted by that server, this feature is not needed. But as soon as you want to start describing any other link relations, or hosting links on e.g. a proxy's resource directory, the anchor feature is right away useful. 

> 10. In Section 3.1, what is "parmname"?

You mean from this:
"     filter-query = resource-param "=" query-pattern
     resource-param = "uri" | parmname
     query-pattern = 1*pchar [ "*" ]
"

This is meant to indicate any target attribute name (parameter name), from RFC5988. In other words, a query string can contain "uri" or any target attribute name defined in RC5988 or the CORE link format. 

Zach

> 
> I'm out of time right now, I might have more comments later or after
> tomorrow's call.
> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: "Stok, Peter van der" <[email-masked]>
Date: Mon, 14 Feb 2011 15:17:57 +0100

Dear Lars Eggert,

I read your draft and had some additional thoughts, not solutions, on the congestion problem.
Congestion in wired networks is caused by routers not consuming and forwarding the packets.
Congestion control also reacts to the rate at which the destination can consume the packets.
The loss of packets has an additional non-intended effect on the congestion behavior.

For low-resource wireless networks, one of the dominating effects may actually be the low link throughput and the interference by many senders, more than the throughput of the routers. The saturation of space around the sender translates itself in long back-off waits.

Consequently, may it not be more natural to measure the back-off time that a packet suffered and use that as indication for the congestion control?

Also I should like to react to the 2-3 second time-out interval. In lighting control applications I expect that most messages will remain local inside the small subnet. I expect that response times of 300 ms are already too long. Consequently, messages may have a deadline of 300 ms attached to them. Once the backoff sequence exceeds 300 ms, a large part of the messages will be rejected and not sent. Accordingly, I expect that steering on deadline may already have a beneficial effect on the congestion problem.

Looking forward to your answer,

Peter van der stok

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.