Subject: [Sip] [Fwd: [Sipping] SIP Subscription for SCADA/Stock quotes]

From: Benjamin Carlyle <[email-masked]>
Date: Wed, 22 Nov 2006 06:25:44 +1000

I haven't recieved any responses on the sipping list. Perhaps someone on
this list can help clarify my concerns:

Subject: [Sipping] SIP Subscription for SCADA/Stock quotes
From: Benjamin Carlyle <[email-masked]>
To: [email-masked]
Date: Fri, 17 Nov 2006 07:34:05 +1000
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>

G'day,

I work for Westinghouse Rail Systems Australia, and am investigating
standard subscription protocols for use in our SCADA product line. SCADA
systems (centralised monitoring and control of remote equipment such as
power distribution systems) tend to rely a lot on subscription to push
data to users and to distributed services. SIP has come up as a possible
way to do this, however at present given my reading of rfc3265 I suspect
it is not appropriate and would like to confirm with this mailing list.

rfc3265 indicates that it is not a general purpose subscription
mechanism. Specific weaknesses I see include
* There is no obvious way to subscribe to a HTTP resource. Subscriptions
are sent to the combination of a SIP url and event package identifier.
* Proxies are used for transport through firewall-intensive networks,
but do not participate in the subscription. A restful architecture is
constrained to support layering, whereby muliple clients who share a
proxy might enjoy a multicasting effect through the proxy
* Data flow is limited by explicit timers. In a SCADA or stock quote
system old data degrades rapidly in value with time, and the objective
is to get as close as possible to immediate notifications. The maximum
notification rate should be related to available bandwidth, or at worst
to network latency
* Subscriptions are refreshed individually at a client-specified rate.
In a SCADA environment we are likely to have thousands of subscriptions
active between a client and server. The client-specified rate may be
used as a keep-alive so that the client can detect server death and
recreate its subscriptions on another cluster member. I believe it is
better for the client to send exactly no renewals. Keep-alive should be
sent from the server only, and at a long reliable rate when no data has
been transmitted over the subscription during the keep-alive interval.

Before I started my quest for an appropriate protocol, I wrote up a
strawman which may be viewed here:
http://soundadvice.id.au/blog/draft-carlyle-sena-00.txt

If I am unable to resolve the issues I have with existing standards I
intend to refine and propose the straw-man as a potential
standards-track rfc. I hope to find that an appropriate subscription
mechanism already exists. I see defining a new one as something of a
last resort.

Security is still a weakness of my protocol when NOTIFY and PATCHNOTIFY
are used. HTTP may only support the EXPIRE notification model without
additional trust mechanisms becoming better understood and deployed.

I believe I have already ruled out the use of XMPP's XEP-0060 given the
way that it makes use of an intermediatary to manage subscriptions but
does not summarise subscription data for slow clients:
http://mail.jabber.org/pipermail/standards-jig/2006-November/012971.html
http://mail.jabber.org/pipermail/standards-jig/2006-November/012974.html
http://mail.jabber.org/pipermail/standards-jig/2006-November/013042.html

Benjamin.

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

---

From: [email-masked]
Date: Tue, 21 Nov 2006 23:03:26 -0500

--=-n4GKOEsNBbkdYY6kkC/2
   Content-Disposition: inline
   [45 lines deleted]

Perhaps you could trim out the 47 lines of redundant headers?

Why is this a "weakness", since RFC 3265 is *intended* as a
SIP-specific subscription mechanism?

A proxy *by definition* doesn't participate in any of the transactions
it forwards.  But you could define an appropriate agent that would
forward data to multiple supplies.

BTW, what is a "restful" architecture?  And what do you mean by
"layering"?

RFC 3265 does not specify any timers for rate-limiting of subscription
notifications, and most implementations do not do much rate-limiting..

   * Subscriptions are refreshed individually at a client-specified rate.
   In a SCADA environment we are likely to have thousands of subscriptions
   active between a client and server.

It seems like you might want to bundle those subscriptions into a
single subscription, if you are using the RFC 3265 model.  Maintaining
thousands of *anything* in a protocol usually indicates an opportunity
for optimization.

   The client-specified rate may be
   used as a keep-alive so that the client can detect server death and
   recreate its subscriptions on another cluster member. I believe it is
   better for the client to send exactly no renewals.

In RFC 3265, subscription refresh is used so that the server can
detect client death.  I suspect that any other subscription protocol
will need a similar mechanism.

   standards-track rfc.

Do you have any reason to believe that there are others out there who
would like to interoperate using a new mechanism?

Dale