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
- [6lowapp] Fwd: New Version Notification for draft… Zach Shelby
- Re: [6lowapp] Fwd: New Version Notification for d… Andreas Scholz
- Re: [6lowapp] Fwd: New Version Notificationfordra… Charles Palmer
- Re: [6lowapp] Fwd: New Version Notification for d… Zach Shelby
- [6lowapp] Fwd: New Version Notification for draft… Xavi Vilajosana Guillen