Re: [6lowapp] CoAp feature analysis

"Van Der Stok, Peter" <peter.van.der.stok@philips.com> Tue, 26 January 2010 11:08 UTC

Return-Path: <peter.van.der.stok@philips.com>
X-Original-To: 6lowapp@core3.amsl.com
Delivered-To: 6lowapp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C71E3A67F5 for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 03:08:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJqi4+uQWzwF for <6lowapp@core3.amsl.com>; Tue, 26 Jan 2010 03:08:22 -0800 (PST)
Received: from smtpx.philips.com (smtpx.philips.com [168.87.56.20]) by core3.amsl.com (Postfix) with ESMTP id F18443A63EC for <6lowapp@ietf.org>; Tue, 26 Jan 2010 03:08:21 -0800 (PST)
Received: from nlamsexh03.connect1.local (172.16.153.24) by connect1.philips.com (172.16.156.42) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 26 Jan 2010 12:08:33 +0100
Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by nlamsexh03.connect1.local ([172.16.152.24]) with mapi; Tue, 26 Jan 2010 12:08:28 +0100
From: "Van Der Stok, Peter" <peter.van.der.stok@philips.com>
To: Zach Shelby <zach@sensinode.com>, Cullen Jennings <fluffy@cisco.com>
Date: Tue, 26 Jan 2010 12:08:20 +0100
Thread-Topic: [6lowapp] CoAp feature analysis
Thread-Index: AcqeAB01s3ejednmQWu58GxmmFlCpgAcXR8A
Message-ID: <B5584ABB89131542BEA01BFAF71A738781E2BC60E7@NLCLUEXM03.connect1.local>
References: <0C0AF10C-85F8-4401-BFB0-441CD08F067E@cisco.com> <4095EBD3-A20F-472D-8D3F-7A1742F55299@sensinode.com>
In-Reply-To: <4095EBD3-A20F-472D-8D3F-7A1742F55299@sensinode.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "6lowapp@ietf.org" <6lowapp@ietf.org>
Subject: Re: [6lowapp] CoAp feature analysis
X-BeenThere: 6lowapp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/6lowapp>, <mailto:6lowapp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowapp>
List-Post: <mailto:6lowapp@ietf.org>
List-Help: <mailto:6lowapp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowapp>, <mailto:6lowapp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2010 11:08:23 -0000

Dear Zach,

I want to send some comments on the CoAP feature analysis draft from a building control point of view.

A picture emerges where a request on general Internet is generated and sent down to the low resources network, which necessitates a translation of HTTP commands to less resource demanding RESTful commands. I like to point out that for building control many (most?) communication originates inside the low resources network and will remain inside that network. However, some commands may remain within the building passing from one low resource network to another, and a smaller fraction will probably generate from outside the building in the general internet network. Efficiency inside the low resources network is more important than efficient translations. My remark does not very much influence the text in the document, but it may have impact on later implementation decisions.

In addition to REQ4 and in conjunction with REQ10, it will be necessary to interrogate on the state of the cached request. A simple statement like: the application is able to check the arrival of the cached request/command will be welcome. How to implement it is a second concern, but when the responsibility is delegated to the application, there remains the problem of waiting for the arrival of the status request by the application.

REQ5. The possibility to subscribe to published data can be made very complex with lots of additional conditions and time constraints within the request. I would suggest that a device can advertise the publication of a fixed set of data with a fixed set of repetition settings (probably a multiple of the sleep interval). Any other sophistication is optional.

REQ8. Although the cited 50ms would be fantastic, their guarantee depends on too many additional operational conditions. A possible phrase is: the multicast results should be delivered in a time comparable to the delivery of the broadcast service provided by the supporting link.
Another point is the scope. Sometimes multicast should be limited to the low resource network limited by the edge router, or should encompass a set of low resource networks (the whole building) possibly identified by a set of prefixes.

REQ10. I don't believe in limiting the reliability to given numbers. The same problem occurs as with response time. The reliability depends on too many other factors. I would be happy with the possibility that the arrival or non-arrival of a message can be tested.

Provision of TCP. When would I use TCP?
(1) reliability: it can tell me whether data arrived (it may say no, although it is yes, but when is says yes, it is yes)
(2) large messages (multiple packets): however the header overhead is such that UDP is preferred at the moment. Large messages can be interesting when descriptions are dumped into a low resource node.
(3) my application on a notebook attached to the building network uses TCP.

In section 2.6 I think to have a slight preference for cache description in the device description. The latter info can be used by the proxy. Difficult to see al consequences though.

I hope this helps a bit.

Peter

Peter van der Stok
Philips Research Laboratories Eindhoven,
High Tech Campus,               HTC 34 (WB) 6-051
5656 AA Eindhoven,              The Netherlands
Phone: +31 40 2749657 ,         Fax: +31 40 2746321
Mailto:  Peter.van.der.Stok@ philips.com

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.