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

Gilbert,

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

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

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

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

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

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

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