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

["Sanjay Sinha (sanjsinh)" <[e-mail]>]

Are there any use cases which require session to be established between
the devices?

 

I am new to this community, but from the discussions that I have seen so
far, looks like most of the use cases require a request-response
transaction and not a session between two devices or groups of devices.
I am also not sure about real time properties that the applications in
this space will have, for which SIP can be used.

 

I would think that SIP event notification mechanism can be used for
things like monitoring the temperature, usage etc. 

 

I am not saying SIP can not be used and I do not have a very good
knowledge of use cases, but I think a starting point would be to come up
with some scenarios where session characteristics can be used.

 

Sanjay

 


 

 

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Arjun Roychowdhury
Sent: Monday, November 02, 2009 2:37 AM
To: Cullen Jennings (fluffy)
Cc: Don Sturek; [e-mail]
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF

 

 

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]
<mailto:[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