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

Andreas Scholz <scholza@in.tum.de> Wed, 24 February 2010 15:07 UTC

Return-Path: <scholza@in.tum.de>
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 C6C553A82F0 for <6lowapp@core3.amsl.com>; Wed, 24 Feb 2010 07:07:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 De3imAC7Z9rO for <6lowapp@core3.amsl.com>; Wed, 24 Feb 2010 07:07:20 -0800 (PST)
Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id B3F9A3A6CA1 for <6lowapp@ietf.org>; Wed, 24 Feb 2010 07:07:17 -0800 (PST)
Received: from [131.159.16.116] (notekemper16.informatik.tu-muenchen.de [131.159.16.116]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.in.tum.de (Postfix) with ESMTP id A5981DAA1 for <6lowapp@ietf.org>; Wed, 24 Feb 2010 16:09:22 +0100 (CET)
Message-ID: <4B854118.2060904@in.tum.de>
Date: Wed, 24 Feb 2010 16:09:12 +0100
From: Andreas Scholz <scholza@in.tum.de>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: 6lowapp@ietf.org
References: <20100218152028.9453E28C0E8@core3.amsl.com> <A73F7E0A-956F-428E-B69B-2C281ED2A154@sensinode.com>
In-Reply-To: <A73F7E0A-956F-428E-B69B-2C281ED2A154@sensinode.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
Subject: Re: [6lowapp] Fwd: New Version Notification for draft-shelby-core-coap-req-00
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: Wed, 24 Feb 2010 15:07:21 -0000

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


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 <idsubmission@ietf.org>
>> Date: February 18, 2010 17:20:28 GMT+02:00
>> To: zach@sensinode.com
>> Cc: Michael.Stuber@itron.com,d.sturek@att.net,brian.tridium@gmail.com,richard.kelsey@ember.com
>> 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. +49 89 289-17292        TU München, Zimmer 02.11.037 FMI
andreas.scholz@in.tum.de     Boltzmannstr. 3, 85748 Garching