RE: [Sipping] SIP Subscription for SCADA/Stock quotes

["Samir Srivastava" <[e-mail]>]

Hi,

  in line.

Thx
Samir

>
>> -----Original Message-----
>> From: Srivastava, Samir (SC100:8826)
>> Sent: Thursday, November 16, 2006 4:47 PM
>> To: Benjamin Carlyle; [e-mail]
>> Subject: RE: [Sipping] SIP Subscription for SCADA/Stock quotes
>> 
>> Do we want to cater the different verticals now ? More in-line.
>> 
>> Thx
>> Samir
>
>Huh? This is a request to evaluate part of SIP framework to 
>see if it is fit for handling a large scale, highly 
>distributed event driven environment. It had better handle it 
>or SIP is in major trouble trying to handle presence. 


If you remember Hennings frustration from the meeting that one bit of
information is going with how many bytes.  SIP presence framework itself
is not that good :-) Though I am not focused on optimizing it currently.

In 2000, there was an attempt on the communication of Intelligent
Appliances...
"SIP Extensions for Communicating with Networked Appliances", H. 
  Schulzrinne, Simon Tsang, Stanley Moyer, Dave Marples, Arjun 
  Roychowdhury, 11/16/2000, <draft-tsang-sip-appliances-do-00.txt>


    A variety of technologies are available to network appliances and 
    provide home automation and control.  However, these do not support 
    wide-area access control and interworking of these Networked 
    Appliances (NA).  This document describes a new SIP method, DO, that

    allows a SIP UA to communicate with NAs. "

If my recollection of arguments on the list is correct, There were
arguments that most of the startups die because of indigestion etc. SIP
is not an infant any more. In the startup mode, you focus on the problem
at the hand. But you keep architecture open such that it can handle
varying needs. It should increase the degree of pervassiveness in the
future seamlessly. I think fathers/god father of SIP were not be having
such a myopic vision on the utility of SIP for just mimicking PSTN and
Presence as you are trying to say. Presence came later and it fit in
well. 

To me, your fear comes from the arguments given by others for weakness
of SIP as "SIP Does many things for many people" . I counter it "IP does
the same", It depends on how you see and design the versatile /
pervassive protocol fulfilling different needs seamlessly with little
extensions where processing intelligence of those extensions is just at
the required end point. Rest nodes are just conduit. To me, Presence in
its current form is just one aspect. SIP in the core is excellent
protocol but with some rough edges coming from mimicking PSTN, etc...

<<SNIP>>

>
>The point of that statement in 3265 and elsewhere is not to 
>limit the URL schemes that can be used, but to point out that 
>there are many ways of pushing data around a network. The 
>intent of the framework wasn't to solve 
>world-event-subscription-hunger. There was a lot of discussion 
>at the time around using (PUBLISH in particular) for all sorts 
>of things and we wanted to constrain the problem space so we 
>could finish off the RFC sometime in our lifetime.

I am not asking world-event-hunger to be fullfilled with this like
X-Motif/JDK event models etc. I am asking only the presence framework to
extend....

<<SNIP>>

>OPTIONS isn't intended to be used as a generic pinging 
>mechanism and has no semantics for keepalive. It is sent to 
>inquire as to the capabilities of an endpoint, and when the 
>linger timer for the transaction pops after sending a 
>response, there is no semantic for keeping track of 
>who/what/when/why an OPTIONS was sent. All an OPTIONS response 
>will typically tell you is that the endpoint's SIP stack is 
>alive. It could be brain-dead above that, and there's no way 
>to know that an OPTIONS failure (for instance a 408 time-out 
>response) is due to a transient network error. Even if you do 
>get a response, it doesn't mean that the subscription is still 
>active on the device.


As per Section 11 of 3261 
   "An OPTIONS request MAY be sent as part of an established dialog to
   query the peer on capabilities that may be utilized later in the
   dialog."

OPTIONS does allow the Allow-Event header etc. There may be sometime
need for a SIP entity to find the state of subscirbe created dialog on
another end, there it will be useful. (Like missing NOTIFY with state
change delta) State indication can be event package specific. 200 OK
with subscription event state tells the querying endpoint what is
happening. If event state is currently not supported, then protocol
might need to extend. Other response codes can be viewed differently.. I
was coining it as he was asking for server driven. I don't understand
completely his problem requirements as of now.


>
>Ben--
>
>RFC-3265 does not have a server-initiated refresh mechanism 
>because the server handling the subscriptions should be 
>spending it's time handling incoming subscription requests, 
>generating notifications, and processing the events that 
>trigger notification. A typical 3265 server implementation 
>will not, for instance, have a timer running for the duration 
>of a subscription. It may simply timestamp the subscription 
>when it is created and then passively garbage collect it later 
>after it expires. Having the much larger set of clients keep 
>track of their timers rather than centralizing the problem is 
>viewed as a better scaling solution because it fans out the 
>work to the largest source of capacity (ie. the clients).

Your point was earlier well understood even before commenting. See the
above.

>
>IMHO- The best way to solve the dead server problem is to have 
>neither end generating keep-alive traffic (which, in an ideal 
>environment in which no node fails, is always useless). Solve 
>the problem at the server by utilizing a high-availability 
>scheme there so that a server failure does not interrupt service.
>

Refer my long time back proposal on the list for the Event based heart
beat 

http://www1.ietf.org/mail-archive/web/sip/current/msg08844.html This was
to avoid the  periodic OPTIONS messages flow when other server was down
to avoid congestion etc.. I was just scratching the congestion at that
time...

Somewhere at the IP layer when packet is sent, it needs to know which IP
server should fill. VRRP just talks about the IP layer connectivity. Can
you describe your scheme...
 

<SNIP>

>Ben--
>
>I've done some work in the past with SCADA, and typically the 
>payload in the event notifications does not require 
>encryption. What you need to typically prevent is someone 
>trying to corrupt your central database with garbage data 
>(indicating faults where there are none, or masking faults 
>where they do exist). This can be handled by request 
>authentication. I believe there are a number of ways to solve 
>this problem depending on the level of assurance that you 
>require for your particular application. You could use HTTP 
>Digest authentication to deal with this, or something heavier 
>such as TLS. Without understanding the security requirements 
>needed, it's going to be hard to evaluate. However, there are 
>a number of models out there already that you can look at to 
>see if there's a fit for your particular purpose.

There were some postings on the HTTP Digest being prone to brute force
attacks.
BTW, I worked earlier in different event based/driven systems too. When
I have more free time, I will start looking into this.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP