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

[Arjun Roychowdhury <[e-mail]>]

On Sat, Oct 31, 2009 at 12:29 PM, Cullen Jennings <[e-mail]> wrote:

>
> On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote:
>
> In order of complexity...
>
>
> 1) simple set of fixed variables that could be controlled
>
> 2) a single flat list of dynamically changeable set of variables that can
> can take on simple types (I might place IPFIX as being somewhat close to
> this model)
>
> 3) a hierarchical list of variables that can be related (I'd place basic
> usage SNMP roughly in this category but more advanced usage of SNMP probably
> can do category 4)
>
> 4) a REST based approach (I'd place HTTP REST in this case)
>
> 5) a full RPC model (I'd place CORBA in this class)
>
> Every use case I have seen so far could be solved by 3, 4, or 5. I think
> most people have expressed an opinion that about 4 looks about the right
> level of flexibility for this. So the questions is, if there is pretty good
> agreement on that, then I think we should just roll with it as tentative
> decision and see what it starts looking like as a design evolves. As the
> design evolves, one may find this was a bogus choice and need to revisit it.
> If you think there is a strong argument for 3 or 5 or even 1 or 2, lets get
> that info out on the list.


ARC> Right. If every use case can be solved by 4, and if an HTTP UA stack is
not an overkill for these devices, then I'd venture out to say that if the
need exists, then we should have a protocol that serves that need. My
argument is for something inbetween 4) and 5) - that is some session
oriented protocol, if one believes there will be sessions and an offer
answer needed. I mention SIP only because that is the one I know well. I am
not religious about SIP, but I am particular about a need.

And now, here is why some of us are putting across the fact that at the
least SIP needs to be evaluated:
(And I know you are well aware of SIP yourself, but I am putting some of
these across for others who may not be)

a) Size/Performance: Simply put, if an HTTP UA is ok, then a minimalistic
SIP UA not being ok is highly suspect. I doubt folks making this statement
have actually evaluated how much a session oriented protocol can be reduced
when it comes to implementation. I've personally worked on SIP UAs that
compress to 30K or less. How much of features you want to put in depends on
the network. Given a network, you can feature compromise. This entire
argument of verbosity vs. optimization is doubtful until you lay down
specific #s that need to be met (and why those #s exist)

b) Can SIP do everything HTTP can?: First, SIP can offer everything HTTP
can. Payloads? check. URI addressing schemes and REST based services. Check.
(http://myhome.com?remote=channel12 can be
sip:[e-mail]<[e-mail]>;channel=12)
etc.

c) What can SIP do better than HTTP?
c.1) Offer-Answer, capability, discovering the minimal feature set that
works between two or more devices

c.2) SIP works on more transport protocols than HTTP (yes, I am aware of
HTTP over UDP, but if we look at live deployments, almost all HTTP systems
use TCP. So if there is a communication needed from a non TCP network to
your HAN, welcome gateways. Almost all SIP deployments I know of today do
both TCP and UDP.)

c.3) Routing & Reachability: SIP's architecture of loose routing, forking,
etc.

c.4) Concept of a 'session' & 'session control' - SIP establishes a session
between one or more devices. These sessions can be transferred to any other
entity if required, monitored, or modified.

Basically, SIP is  HTTP+Sessions and an architecture to manage sessions.

1) what other protocols mapping should we do?
>
> 2) Given some people want HTTP, can you live with the answer to HTTP being
> yes and understanding that just because we said yes to HTTP does not mean we
> are saying no to everything else?
>
>
ARC> 1) SIP.
2) Yes.

-- 
Arjun Roychowdhury