Re: [6lowapp] Proposed charter for 6LoWAPP BOF

["Adriano Pezzuto (apezzuto)" <[e-mail]>]

Hi Zach and Robert,
I get the point. It sounds good.

Thanks,
Adriano

>>  If (2) were done there would probably be no point in doing (1) or  
>> (3). (3) could be done now but does not solve the requirement for  
>> "end-to-end", although there are a number of possibilities there if  
>> you split the application layer into the three layers defined in  
>> OSI, but that's another debate.

> I think you hit on the whole point here. 1 is done, 2 is not possible,  
> and what this WG needs to do is 3, making that as integrated into the  
> web architecture as we can. If we do our job well, I don't see  
> proxying between two protocols that share the same semantics (URLs,  
> REST etc.) and leave the payload alone to be a problem.



-----Original Message-----
From: Zach Shelby [mailto:[e-mail]] 
Sent: mercoledì 4 novembre 2009 22.52
To: [e-mail]
Cc: Adriano Pezzuto (apezzuto); Paul Duffy (paduffy); [e-mail]
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF

Robert,

Very good points below, thanks for the mail!

On Nov 4, 2009, at 18:35 , Robert Cragie wrote:

> (1) pushes from the wider Internet to the edge devices.
> (2) pushes from the edge devices to the wider Internet.

Yep, this is the tussle at play here. We are not considering all edge  
devices here, only the most constrained devices and networks.

> Therefore I see three ways of proceeding:
> 	* Define an application protocol which uses RESTful HTTP over TCP  
> extending to the edge devices and try to find a solution to the  
> problems of TCP over lossy links

So HTTP already is that protocol, and it is the current SOTA for  
embedded devices and networks where it gets the job done. We already  
determined that new transport work is a longer-term issue for the TSV  
area. The whole point of this interest group (and WG effort) is that  
there is a large set of devices, networks and applications where this  
is not sufficient. So I would say that 1 is definitely done.

> 	* Define an application protocol based on a universal transaction  
> and transport which is flexible enough for all media and takes into  
> consideration the underlying properties of the medium through cross- 
> layer controls. However the scope of this work is probably beyond  
> CoAP and assumes that IPv6 would become pervasive enough not to  
> cause problems with existing infrastructure

This is out of scope of the APP area, and probably breaks lots of IETF  
architectural concepts as well. So 2 is out.

> 	* Define new application, transaction and transport protocols  
> oriented towards CNets and define a proxy model for extension into  
> the wider Internet

This WG is not going to define new transport protocols (nor can it).  
There is good consensus to use UDP by default and allow for the use of  
TCP (or other suitable transports).

> Note these are not mutually exclusive. If (1) were done, (3) could  
> still be a solution for devices which do not meet the criteria to  
> satisfy the use of TCP.

TCP is only one issue, it is useful in some cases. HTTP and current  
security models assumed by the web infrastructure are not suitable for  
all constrained IP devices and networks.

>  If (2) were done there would probably be no point in doing (1) or  
> (3). (3) could be done now but does not solve the requirement for  
> "end-to-end", although there are a number of possibilities there if  
> you split the application layer into the three layers defined in  
> OSI, but that's another debate.

I think you hit on the whole point here. 1 is done, 2 is not possible,  
and what this WG needs to do is 3, making that as integrated into the  
web architecture as we can. If we do our job well, I don't see  
proxying between two protocols that share the same semantics (URLs,  
REST etc.) and leave the payload alone to be a problem.

Now. Considering that, do you have comments on the charter text? We  
are working on a new version right now.

Zach

>
> Regards,
>
> Robert
>
> Adriano Pezzuto (apezzuto) wrote:
>> Hello,
>> I don't get one point here. Help me to understand.
>> Are we searching for a well known protocol to use as CoAP for  
>> 6lowPAN and WSN networks or are we searching for a "model" to use  
>> for?
>>
>> I'm seeing here a lot of proposal like HTTP, SNMP, SIP, XMPP on the  
>> plate. Each of these protocols have been developed for a specific  
>> purpose keeping in mind specific constraints and requirements and  
>> each of them is a valid choice for the respective domain. On the  
>> other side, each of them have some drawbacks for 6lowPAN and WSN  
>> networks and I see a lot of diverged opinions here.
>>
>> Why we fear for define a new application protocol especially  
>> designed for 6lowPAN and WSN networks?
>>
>> I'm a newbie for 6lowPAN but my feeling is that a simple  
>> lightweight protocol (I also prefer LoAP instead of CoAP) with a  
>> minimal set of primitives (e.g. SET/SET-Reply, GET/GET-Reply and  
>> Event/Ack) is sufficient to cover the most part of the use cases  
>> and interaction models for 6lowPAN and WSN networks. Other items  
>> can be further added on the plate like security, service discovery,  
>> nodes and network management, and so on .. but all they can be  
>> solved with the same minimal approach keeping in mind the real  
>> nature and the scope of 6lowPAN networks. At the end of day, we are  
>> talking about CSMA/CA radio networks with high lossy and few  
>> kilobytes of useful throughput. Also the nodes spend most part of  
>> their time sleeping down to save power or can be inactive for days  
>> (or months). I've some doubts that complex protocols/frameworks  
>> (developed for other scopes than 6lowPAN) can run efficiently on  
>> our small poor devices. But that's only the feeling of a newbie ....
>>
>> Adriano
>>