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

[Shidan <[e-mail]>]

Yes, we actually have discussed in depth many use cases and something on
both my plate and Arjun's is to share use cases and and a white paper with
this group on benefits of using a binary SIP protocol. We will include a
matrix of summarizing some of the concerns that members of this group have
shown with real numbers, which is something I think is really needed.
Hopefully this will be of help to the group in Hiroshima.

"I think Paul is talking about verbose nature of SIP and also the parsing of
headers and message body that is required and whether the processing cost
fits into the requirement for low power embedded devices."

This is valid a valid concern and I think after understanding the system we
are proposing, you will be pleasantly surprised.

---
Shidan Gouran

On Sun, Nov 1, 2009 at 11:56 PM, Sanjay Sinha (sanjsinh) <[e-mail]
> wrote:

>  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]<[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
>
> _______________________________________________
> 6lowapp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lowapp
>
>