Re: [6lowapp] Reliability Requirements in draft-shelby-6lowapp-coap-00
"G. Clark" <gc355804@ohio.edu> Fri, 12 February 2010 22:37 UTC
Return-Path: <gc355804@ohio.edu>
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 0690E28C169 for <6lowapp@core3.amsl.com>; Fri, 12 Feb 2010 14:37:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.178
X-Spam-Level:
X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599]
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 z4jmM1NkH9GD for <6lowapp@core3.amsl.com>; Fri, 12 Feb 2010 14:37:09 -0800 (PST)
Received: from mx4.oit.ohio.edu (mx4.oit.ohio.edu [132.235.250.54]) by core3.amsl.com (Postfix) with ESMTP id BA12A28C14B for <6lowapp@ietf.org>; Fri, 12 Feb 2010 14:37:09 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApsEAFJndUuE6wiX/2dsb2JhbACbf7IDDoQgiFWCTIIMBIMT
X-IronPort-AV: E=Sophos;i="4.49,463,1262581200"; d="scan'208";a="29304836"
Received: from oak3a.cats.ohiou.edu (HELO oak.cats.ohiou.edu) ([132.235.8.151]) by smtpout4.oit.ohio.edu with ESMTP; 12 Feb 2010 17:38:29 -0500
Received: from wrath.cs.ohiou.edu (wrath.cs.ohiou.edu [132.235.3.135]) (authenticated bits=0) by oak.cats.ohiou.edu (8.13.1/8.13.1) with ESMTP id o1CMbZaF1937322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Feb 2010 17:37:40 -0500 (EST)
Message-ID: <4B75D82F.6060508@ohio.edu>
Date: Fri, 12 Feb 2010 17:37:35 -0500
From: "G. Clark" <gc355804@ohio.edu>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Zach Shelby <zach@sensinode.com>
References: <4B704E48.4030000@in.tum.de> <105CAD44-328B-497F-BBFE-DDFD692FEB58@sensinode.com>
In-Reply-To: <105CAD44-328B-497F-BBFE-DDFD692FEB58@sensinode.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] Reliability Requirements in draft-shelby-6lowapp-coap-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: Fri, 12 Feb 2010 22:37:11 -0000
Hi: A quick question / comment: Zach Shelby wrote: > Andreas, > > On Feb 8, 2010, at 18:47 , Andreas Scholz wrote: > > >> As a short introduction: I am writing my Ph.D. thesis in the area of constrained networks for control and automation. So I have a rather automation-oriented point of view on the requirements for an application protocol. >> >> I have a remark regarding REQ10 in the CoAP draft. It states "Reliability must be provided for application layer messages". I am not sure that really all application layer messages have to be transmitted reliably. Consider for example a temperature sensor that provides readings on a frequent basis, e.g., every second. Based on the application that uses this data, a loss of a single packet (or even a bursty loss of multiple messages) may be tolerable. I am thinking of an application that controls a heater, or a monitoring application. In fact a retransmission of lost messages might even be a problem if this delays the transmission of the newly acquired data values. On the other hand there a plenty of messages that have to be transmitted reliably. >> > > Good point. My own assumption is that the reliability feature over UDP can be shut off when not needed. > > I did notice that in section 2.8.1 (wrt UDP transport), the draft said: "Stop-and-wait would be sufficient for reliability. A simple response message itself would suffice as an acknowledgement with retransmission support. Not all requests require reliability, thus this should be optional." I found this to be a bit confusing, though: how do we meet REQ10 without enforcing reliability in requests? >> I think it is very difficult to find a general set of such requirements (and other QoS requirements such as latency etc) that is suitable for all applications running in a resource constained network. Because QoS requirements are typically application specific, the subscriptions could be a good location for specifiying such requirements. I am thinking about a subscription mechanism that allows a subscriber to not only specify the resource he is interested in, but also additional parameters such as reliability. This could also be an interesting way for switching between UDP and TCP based communication; a subscriber could specify that the data should be delivered via TCP instead of the default transmission via UDP. >> > > This is something to consider wrt subscription, I could add some text about that to draft-shelby-6lowapp-coap. > Instead of including TCP / UDP in the subscription request, would it be a bad plan to encode reliability in a service's URL? e.g. coap[s]://my.device/reliable/service. In this way, you could also mirror services (coap[s]://my.device/xyz, coap[s]://my.device/reliable/xyz) pretty easily. This does have the downside of introducing more overhead, and it wouldn't be practical for multiple options to be encoded this way. This approach would move the decision for reliable / non-reliable transport to the application layer. >> Based on such a subscription mechanism, a node would also be able to reject subscriptions based on the specified non-functional parameters. For example because it possesses no protocol that supports reliable message transmission, or because it has not enough free memory to support an additional reliable connection (which requires storing sent messages). >> > > Definitely! > > Zach > > Regards, Gilbert Clark Grad Student Ohio University >> Best regards >> >> Andreas >> >> -- >> 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 mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> > >
- [6lowapp] Reliability Requirements in draft-shelb… Andreas Scholz
- Re: [6lowapp] Reliability Requirements in draft-s… Zach Shelby
- Re: [6lowapp] Reliability Requirements in draft-s… G. Clark
- Re: [6lowapp] Reliability Requirements in draft-s… Zach Shelby
- Re: [6lowapp] Reliability Requirements in draft-s… G. Clark