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

[Zach Shelby <[e-mail]>]

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

> 
> 
> Best regards
> 
> Andreas
> 
> 
> Zach Shelby schrieb:
>> 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 <[e-mail]>
>>> Date: February 18, 2010 17:20:28 GMT+02:00
>>> To: [e-mail]
>>> Cc: [e-mail],[e-mail],[e-mail],[e-mail]
>>> 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.
>>> 
>>> 
>>>    
>> 
>>  
> 
> -- 
> Andreas Scholz               Lehrstuhl Informatik III
> Tel. [phone]        TU München, Zimmer 02.11.037 FMI
> [e-mail]     Boltzmannstr. 3, 85748 Garching
> 
> _______________________________________________
> 6lowapp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lowapp

-- 
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: [phone]

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.