Subject: [6lowapp] Fwd: New Version Notification for draft-shelby-core-coap-req-00

From: Zach Shelby <[email-masked]>
Date: Thu, 18 Feb 2010 17:26:21 +0200

Hi,

http://www.ietf.org/id/draft-shelby-core-coap-req-00.txt

I updated draft-shelby-6lowapp-core-00 with all the comments (hopefully!) from the list, and renamed it to match the new CoRE WG and a more descriptive title. This now should be in alignment with the latest charter proposal, and the thoughts on the mailing list. If there are sufficient comments,  I'm happy to spin another version before the Anaheim deadline.

We'll now be working on an initial CoAP protocol specification draft before the -00 submission deadline, at least a very initial version, to discuss in Anaheim. So any input/ideas on protocol design welcome on the list also a-priori as the cutoff is Mar 1st already! 

Regards,
Zach

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: February 18, 2010 17:20:28 GMT+02:00
> To: [email-masked]
> Cc: [email-masked],[email-masked],[email-masked],[email-masked]
> Subject: New Version Notification for draft-shelby-core-coap-req-00 
> 
> 
> A new version of I-D, draft-shelby-core-coap-req-00.txt has been successfuly submitted by Zach Shelby and posted to the IETF repository.
> 
> Filename:	 draft-shelby-core-coap-req
> Revision:	 00
> Title:		 CoAP Requirements and Features
> Creation_date:	 2010-02-18
> WG ID:		 Independent Submission
> Number_of_pages: 18
> 
> Abstract:
> This document considers the requirements and resulting features
> needed for the design of the Constrained Application Protocol (CoAP).
> Starting from requirements for energy and building automation
> applications, the basic features are identified along with an
> analysis of possible realizations.  The goal of the document is to
> provide a basis for protocol design and related discussion.
> 
> 
> 
> The IETF Secretariat.
> 
> 

-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof.

---

From: Andreas Scholz <[email-masked]>
Date: Wed, 24 Feb 2010 16:09:12 +0100

Hi Zach,

I have an input w.r.t. the performance/message size issues outlined in 
the draft.

I think one has to distinguish between two kinds of interactions in a 
constrained network: subscription based interactions and ad-hoc 
interactions. In the (building) automation scenarios I can think of, 
ad-hoc interactions occur only very rarely. Instead most of the network 
messages stem from the control applications, which use dedicated 
communication partners. A good way to decrease the message overhead is 
to support these subscription based interactions as efficient as possible.

The idea used by EXI to reduce the size of messages is to exploit common 
knowledge on both ends of the communication channel. If both partners 
have agreed upon a message scheme, defined as XML Schema document, all 
the information contained in the schema can be omitted during 
transmission. I think a similar approach can be used to support the 
efficient transmission of subscription based messages. When a subscriber 
and a remote endpoint set up a subscription, a lot of the information 
contained in a typical message header will already be defined in the 
subscription. The content type of incoming messages, the encoding type, 
even the source and target endpoint are all known from the subscription. 
By applying the technique used in EXI to the protocol header, all these 
fields could be replaced by a single subscription identifier. On the 
client side this information can be reconstructed (if needed) based on 
the subscription definition. An interesting property of this mechanism 
is, that the information regarding encoding, content-type etc is only 
transmitted when the subscription is established. A "verbose" format is 
therefore not a big problem.

Of course this mechanism is not applicable for ad-hoc requests. The 
question is how frequent these ad-hoc interactions are and how much 
effort should be invested to reduce the message size of ad-hoc requests 
and responses. Of course the application protocol should still be 
efficient. But given a mechanism like the one mentioned above, the 
question is how much flexibility should be traded for performance if the 
actual savings influence only a small part of the transmitted messages.

Anyway, I think a header format that allows omitting information that is 
known a priori (e.g. from a subscription) is a promising approach for 
reducing message overheads.

Best regards

Andreas

-- 
Andreas Scholz               Lehrstuhl Informatik III
Tel. +49 89 289-17292        TU München, Zimmer 02.11.037 FMI
[email-masked]     Boltzmannstr. 3, 85748 Garching

---

From: "Charles Palmer" <[email-masked]>
Date: Thu, 25 Feb 2010 23:34:05 -0000

Dear 6lowapp team

Andreas suggests that knowledge shared by both parties can allow much
reduced message sizes: "I think a header format that allows omitting
information that is known a priori (e.g. from a subscription) is a
promising approach for reducing message overheads."

Has anyone looked at the approach adopted by the IEEE 11073 standards
for exchange of messages between Personal Health Devices and their
"Managers"? This transport-agnostic set of standards is designed to
connect a wide variety of wireless personal health devices and assisted
living devices - so far using Bluetooth and ZigBee but (who knows) maybe
6lowpan in the future. When I have time I will finish this Wikipedia
introduction article:
http://en.wikipedia.org/wiki/User:Acutetech/ISO/IEEE_11073_Personal_Heal
th_Data_%28PHD%29_Devices

IMHO the IEEE 11073 standards for Personal Health Devices could easily
be generalised to support any class of M2M device.

The IEEE 11073-20601 standard uses several techniques to reduce message
size, and to simplify "discovery" - these might be worth considering for
6lowapp. (The terminology is different but the problems are the same).
Two techniques are:

1	A personal health device ("Agent" in IEEE11073 parlance) may
either implement one or more standard configurations, or may implement
an extended (custom) configuration. When an Agent first associates with
a PC, smart phone etc ("Manager" in IEEE 11073 parlance) it states its
configuration code. Usually the Manager will already have knowledge of
the object model of Agents with this configuration code - either because
it was given this knowledge at birth, or because it has previously
associated with this Agent and has already learnt its object model. If
the Manager does not have knowledge of this configuration it asks the
Agent to describe its characteristics (by listing its objects).

The use of standard configurations, and the exchange of object models
when an Agent with a new configuration appears for the first time,
significantly reduces the exchange of data required when an Agent
associates with a Manager.

2	During this configuration phase the Agent and Manager also agree
one or more "attribute-value-maps". These pre-define the format of
subsequent data exchanges. The standard says this:

"The fixed format event report is optimized by defining the message
format in the Attribute-Value-Map of the object in a previous
configuration message before transfer commences. When an agent transmits
data in a fixed format event report, it shall report the object handle
and the attribute values in the same order and size as specified in the
Attribute-Value-Map. In this way, the overhead of sending attribute
identification and length in each event report is avoided. On receipt of
a fixed format event report, the manager uses the object handle to
retrieve the Attribute-Value-Map previously given at configuration time
to know how to extract the data."

Also - I don't know if it is too late to suggest that 6lowapp
reconsiders the merits of ASN.1 rather than EXI. IEEE 11073 has adopted
ASN.1 to encode messages for transmission. This allows for very simple
"canned" messages from constrained devices, in which the variable data
is inserted at defined offsets into fixed-format ASN.1 binary message
strings. ASN.1 is also used by DLMS - one of the smart meter standards.
A challenge: write practical implementations of EXI and ASN.1 encoding
and decoding routines in C, then compare the size and complexity of the
code, and of the message strings. 

Regards - Charles Palmer 
Onzo Limited (Project Hydra Project Manager) 
Woodthorpe, Calver Road, Baslow, Derbyshire, DE45 1RR, United Kingdom 
Ph: +44 (0)1246 582 220, Mob: +44 (0)7977 577 627 
Email: [email-masked] Skype: Acutetech

--------------------------------
Onzo is a limited company number 06097997 registered in England & Wales. The    
registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom.

This email message may contain confidential and/or privileged information, and
is intended solely for the addressee(s). If you have received this email in     
error, please notify Onzo immediately. Unauthorised copying, disclosure or 
distribution of the material in this email is forbidden.
--------------------------------

---

From: Zach Shelby <[email-masked]>
Date: Fri, 26 Feb 2010 15:30:05 +0200

Hi Andreas,

On Feb 24, 2010, at 17:09 , Andreas Scholz wrote:

> Hi Zach,
> 
> I have an input w.r.t. the performance/message size issues outlined in the draft.
> 
> I think one has to distinguish between two kinds of interactions in a constrained network: subscription based interactions and ad-hoc interactions. In the (building) automation scenarios I can think of, ad-hoc interactions occur only very rarely. Instead most of the network messages stem from the control applications, which use dedicated communication partners. A good way to decrease the message overhead is to support these subscription based interactions as efficient as possible.

I am not sure I understand the difference between these types of interactions. I agree that most interactions in the scenarios that I work with tend to be "subscription based".

> 
> The idea used by EXI to reduce the size of messages is to exploit common knowledge on both ends of the communication channel. If both partners have agreed upon a message scheme, defined as XML Schema document, all the information contained in the schema can be omitted during transmission. I think a similar approach can be used to support the efficient transmission of subscription based messages. When a subscriber and a remote endpoint set up a subscription, a lot of the information contained in a typical message header will already be defined in the subscription. The content type of incoming messages, the encoding type, even the source and target endpoint are all known from the subscription. By applying the technique used in EXI to the protocol header, all these fields could be replaced by a single subscription identifier. On the client side this information can be reconstructed (if needed) based on the subscription definition. An interesting property of this mechanism is, that the information regarding encoding, content-type etc is only transmitted when the subscription is established. A "verbose" format is therefore not a big problem.

I see where you are going. In addition to the state setup when making a subscription, the resource discovery feature also offers some out-of-band information. For example, we can assign an 8-bit integer to each URL to avoid sending string URLs. 

Now when doing this, we must be careful not to break e.g. caching by an intermediate. In the case of a cache, it would be a good idea to include enough information in the notification sent as a result of subscriptions so that it can refresh the cached resource. If the notification would just include a subscription ID, that requires the cache to also store that state. Is that a problem?

> 
> Of course this mechanism is not applicable for ad-hoc requests. The question is how frequent these ad-hoc interactions are and how much effort should be invested to reduce the message size of ad-hoc requests and responses. Of course the application protocol should still be efficient. But given a mechanism like the one mentioned above, the question is how much flexibility should be traded for performance if the actual savings influence only a small part of the transmitted messages.

By ad-hoc I think you are referring to a Req/Res style READ or WRITE message using CoAP? In that case you are right, there isn't a subscription setup. As I mentioned above, even in that case we can encode the URL as an integer. 

> 
> Anyway, I think a header format that allows omitting information that is known a priori (e.g. from a subscription) is a promising approach for reducing message overheads.

Agreed. Let's see what we can get into the first draft of CoAP which I'm trying to finish for the March 1st deadline.

Thanks,
Zach

> _______________________________________________
> 6lowapp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowapp

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND