Subject: [6lowapp] Reliability Requirements in draft-shelby-6lowapp-coap-00

From: Andreas Scholz <[email-masked]>
Date: Mon, 08 Feb 2010 18:47:52 +0100

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.

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.

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).

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: Zach Shelby <[email-masked]>
Date: Fri, 12 Feb 2010 12:26:46 +0100

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 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.

> 
> 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

> _______________________________________________
> 6lowapp mailing list
> [email-masked]
> 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: +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: "G. Clark" <[email-masked]>
Date: Fri, 12 Feb 2010 17:37:35 -0500

Hi:

A quick question / comment:

> 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?
> 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 suppor…
Regards,
Gilbert Clark
Grad Student
Ohio University

---

From: Zach Shelby <[email-masked]>
Date: Mon, 15 Feb 2010 12:47:53 +0200

Gilbert,

On Feb 13, 2010, at 0:37 , G. Clark wrote:

> 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?

The Section 2.8.1 text is correct. It is REQ10 that is a bit misleading. The protocol is required to have a reliability feature, but the application isn't required to use it ;-) I'll update that in the -01 spin (coming this week).

> 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.

Reliability should be controlled by the application layer originating a message. For TCP/UDP this is simply done with a Socket API. For the UDP reliability feature, this can be a flag in the header of the message, for example an "ACK ME" flag. In that way a resource (URL) is not dependent on the protocol features used to access it. Makes sense? 

Zach

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

---

From: "G. Clark" <[email-masked]>
Date: Mon, 15 Feb 2010 08:05:20 -0500

> The Section 2.8.1 text is correct. It is REQ10 that is a bit misleading. The protocol is required to have a reliability feature, but the application isn't required to use it ;-) I'll update that in…
Ah hah!  Got it; thanks.
> Reliability should be controlled by the application layer originating a message. For TCP/UDP this is simply done with a Socket API. For the UDP reliability feature, this can be a flag in the header…
It does; thanks!  I'm not sure I completely understand here, though; 
mind clarifying why don't we want a resource to be dependent on protocol 
features?  I can think of a few cases where I'd only want to offer 
access to a service over UDP as opposed to TCP, for example.
> Zach
Thanks,
Gilbert