Subject: [Sipping] comments on draft-rosen-sipping-cap-00

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Jul 2007 23:11:46 -0400

I have a bunch of questions and comments on how this would work.

Firstly, what is the URI that a phone subscribes to for this? Is there 
going to be a well known 'cap' URI that everyone subscribes to, in order 
to get these alerts?

What is the scale of this? So far we've used the event framework in 
cases where the number of subscriptions to a particular resource were 
relatively small (compared to the total subscriber population). But if, 
in this case, every UA has a subscription to this package, and all of 
the subscriptions are to the same URI, this is a scale requirement that 
is beyond what we have considered, and I have no doubt that there would 
be issues.

This is an application where it starts to get really fuzzy where the 
line gets drawn between state notifications and pager-mode MESSAGE. 
Indeed, in your use case there really isn't state at all - its merely 
notifications on relevant events. So, things like polling and SUBSCRIBE 
refresh aren't well defined.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Jul 2007 09:27:09 +0200

Hi Jonathan,

I have to admit that the authors of the draft had some disagreement 
about some of the details.

Here is my impression how this early warning application should work:

* A SIP UA uses LoST to discover the URI of the server that is 
responsible for a specific geographical region.
Even though the boundaries of individual alerts are specific to that 
alert a set of servers (from an organization) may be responsible to 
cover a certain region.

* Then, the SIP UA that is interested in specific alerts in a particular 
region subscribe to a category of alerts.

It is true that the load can be quite high if the number of parties 
interested in alerts of a particular region is pretty high.
Typically, I do, however, expect that not everyone is interested in all 
alerts throughout the world. When I travel to Chicago then I might be 
interested in alerts in that particular area and not in alerts in 
Austria (unless I have relatives there).

Does this make sense to you?

Ciao
Hannes

Jonathan Rosenberg wrote:
> going to be a well known 'cap' URI that everyone subscribes to, in 
> order to get these alerts?
>
> relatively small (compared to the total subscriber population). But 
> if, in this case, every UA has a subscription to this package, and all 
> of the subscriptions are to the same URI, this is a scale requirement 
> that is beyond what we have considered, and I have no doubt that there 
> would be issues.
>
> notifications on relevant events. So, things like polling and 
> SUBSCRIBE refresh aren't well defined.
>
> -Jonathan R.
>
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 17 Jul 2007 10:01:32 -0400

So the assumption is that alerts are always geographically scoped? Seems 
like it would be hard to define what that scope is, and that it would 
depend on the area. Certainly there is precedent for US-wide alerts 
(9/11 for example). Is that in scope? How would that work?

My main comment is, I think this is the stuff you need to write down, 
not so much the details of the event package registration, which is 
mostly what is in here.

-JOnathan R.

---

From: [email-masked]
Date: Tue, 17 Jul 2007 21:31:32 -0400

There are a number of important issues that aren't being addressed
here:

- Ability to restrict announcements to an area of interest.  As
  others have said, most announcements are likely to be of interest in
  only a small area.  Being able to restrict a subscription to the
  messages of interest should reduce the message load by a large
  factor, as well as prevent the recipient from being buried in a
  clutter of irrelevant messages.

- Event updates are not expected to be delivered very quickly.  While
  telephony status updates are expected in the sub-second timeframe,
  emergency announcements can have delivery times on the order of
  minutes.

- We've observed in PBX systems that the vase majority of the
  signaling load is maintaining registrations and subscriptions.
  Emergency announcement subscriptions are even more extreme -- it is
  easy to imagine millions of subscriptions to an event which is
  signaled less than once a year.  To maintain those at the default
  refresh rate requires 277 resubscriptions per second.

The above two factors argue that the optimal architecture may be very
different from SUBSCRIBE/NOTIFY.

- Other uses.  I expect this mechanism to be adopted quickly by many
  services that now use pager-based announcements.  I know that there
  are services that provide alerts when a stock price changes, and in
  Los Angeles there are alerts for police high-speed chases.  These
  uses are likely to be higher volume than public safety announcements.

Dale

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Jul 2007 10:12:02 +0200

Hi Jonathan,

Jonathan Rosenberg wrote:
> So the assumption is that alerts are always geographically scoped?

That was at least the model I had in mind. I am sure there are folks out 
there with a different idea to tackle the problem.

Essentially, I could envision two factors to deal with scalability. You 
can scope alerts by geographical regions and by the type of alerts you 
want to subscribe.

> Seems like it would be hard to define what that scope is, and that it 
> would depend on the area. Certainly there is precedent for US-wide 
> alerts (9/11 for example). Is that in scope? How would that work?
Large scale disasters are not the typical case. Still, it is important 
to have a sound story for them.

Here is how I could see that this could work: Someone needs to be 
authoritative for issuing the alerts -- already from an authorization 
point of view not everyone is allowed to send alerts for a good reason. 
Typically, there are national regulations in place to indicate who is 
responsible for which alerts and for which parts of the country.

Consider that an entity A is responsible for region(A). Now, a 
particular disaster affects a region(A1) where A1 is contained in A. In 
this case there isn't a problem at all.

If, however, the disaster affects a larger region(ABC) then the entities 
A, B and C need to exchange some information in order to populate 
information about the disaster to their interested subscribers as well.

> not so much the details of the event package registration, which is 
You are certainly right. As we worked on architectural challenges in 
ECRIT I would expect todo the same on this topic.

Ciao
Hannes

>> * Then, the SIP UA that is interested in specific alerts in a 
>> particular region subscribe to a category of alerts.
>>
>> Typically, I do, however, expect that not everyone is interested in 
>> all alerts throughout the world. When I travel to Chicago then I 
>> might be interested in alerts in that particular area and not in 
>> alerts in Austria (unless I have relatives there).
>>
>>> Firstly, what is the URI that a phone subscribes to for this? Is 
>>> there going to be a well known 'cap' URI that everyone subscribes 
>>> to, in order to get these alerts?
>>>
>>> cases where the number of subscriptions to a particular resource 
>>> were relatively small (compared to the total subscriber population). 
>>> But if, in this case, every UA has a subscription to this package, 
>>> and all of the subscriptions are to the same URI, this is a scale 
>>> requirement that is beyond what we have considered, and I have no 
>>> doubt that there would be issues.
>>>
>>> Indeed, in your use case there really isn't state at all - its 
>>> merely notifications on relevant events. So, things like polling and

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Jul 2007 10:18:07 +0200

Hi Dale,

thanks for your feedback. Some comments below:

>   clutter of irrelevant messages.
You are certainly right. This is also my assumption.

There are two ways todo this:
* First, when you use LoST then you only get a URI of the entity that is 
responsible for a specific geographical region (and for a particular 
type of alert).
* Second, when you issue a SUBSCRIBE to the previously obtained server 
you might further reduce the area of interest by including location 
information.
>   emergency announcements can have delivery times on the order of
I am not so sure about that. I think it depends on the nature of the 
disaster. In some cases you might indeed have more time.
But I am sure that there are numbers available that give some guidance 
on how fast these updates need to be delivered. I will try to find them.

> different from SUBSCRIBE/NOTIFY.
I also see scalability challenges. Do you have a suggestion how to deal 
with them?

>   uses are likely to be higher volume than public safety announcements.
Correct. The requirements for these type of services are certainly 
different than the onces we have described in 
http://tools.ietf.org/wg/ecrit/draft-norreys-ecrit-authority2individuals-requirements-00.txt

Ciao
Hannes

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Jul 2007 09:58:51 -0400

I share the concerns of Jonathan and Dale.

I think it is essential to describe in a document the intended 
architecture of the system in which this mechanism will be deployed. It 
need not be normative, but could instead be part of a set of requirements.

The geographical nature of this, if there is one, is important to 
understand. I don't necessarily buy that the events are themselves 
always geographically oriented, so the use of a per-geography target for 
subscriptions seems to be more of an optimization. As Hannes noted 
somewhere in this thread, the relevant geographical area for a 
particular alert may span the areas of multiple notifiers. So it might 
be necessary for the publication architecture to broadcast alerts, or 
something to that effect.

Also, this apparently spans alerts pertaining to many subjects. There is 
likely to be a need for a filter mechanism so that a subscriber can 
identify the sorts of alerts of interest.

In terms of "event state", I think there needs to be some explanation of 
how the publication of an alert affects state within the compositor, and 
how long the resulting state remains in effect.

I wonder if an email based mechanism might not be better for this sort 
of service.

	Paul

---

From: David R Oran <[email-masked]>
Date: Wed, 18 Jul 2007 15:16:05 -0400

> I share the concerns of Jonathan and Dale.
Me too.

> architecture of the system in which this mechanism will be  
> deployed. It need not be normative, but could instead be part of a  
> set of requirements.
>
As a first attempt to give the architectural characteristics, let me  
offer the following "top level" observations:
- The number of potential recipients of emergency notifications is  
very large, even for a single notification - perhaps O(10**7) for a  
large metropolitan area.
- The authority issuing the alerts in general has no interest in  
knowing who is listening for the notifications
- The authority is mostly interested in ensuring that those who  
wished to be notified had a high probability of receiving the  
notifications.
- The authority likely has little interest (but perhaps some) in  
knowing who got the notifications and who did not
- The "type space" of emergency notifications is not very small, but  
also not very large, and likely has a slowly-changing schema.
- Interest based on type of event (weather, crime, fire, etc.) is  
likely to vary among the parties interested in receiving the  
notifications.
- As others have pointed out, geographical affinity/filtering is  
likely to be mandatory for sanity if not for scalability.
- Authorization of who is permitted to receive notifications is  
likely to be loose (e.g. anyone) for most events.
- Those events that require tight authorization (e.g. bomb might be  
near Times Square) are unlikely to have the large scalability  
requirements of the class above.

Perhaps we could use this as a starting point for some requirements  
and technical tradeoff analysis?

My gut feeling is that the existing subscribe/notify architecture can  
probably be directly adopted only for the last category of things  
(those needing tight authorization).

For the kind of broad-scale notification I might use the general URI  
addressing and event-package schema methods for describing the event  
types, region of interest, etc. but using the existing subscription  
state maintenance and notification machinery is likely to just beg  
for meltdowns and DoS attacks.

So, to violate the "requirements first" dictum as any "real engineer"  
is wont to do, let me suggest what I think would be a near-ideal  
approach.

- Use SUBSCRIBE only in the "one shot" mode so we can re-use the  
addressing and schema of the SIP evnets architecuture.
- The SUBSCRIBE returns a 302 to a multicast-service URI, which just  
gives two pieces of information (a) an IP SSM address/port to listen  
to for notifications, (b)a GDOI group key for the group, encrypted  
under some key derived during authorization (to prevent leakage in  
the case the information is sensitive).
- The actual notifications are sent on the multicast address, using  
SSM. The GDOI key allows for timeout-based key rotation is necessary
- The notifications are source-coded using a rateless FEC to give a  
flexible tradeoff between notification rate, bandwidth utilization,  
delay-to-reception, and error resilience.

> always geographically oriented, so the use of a per-geography  
> target for subscriptions seems to be more of an optimization. As  
> Hannes noted somewhere in this thread, the relevant geographical  
> area for a particular alert may span the areas of multiple  
> notifiers. So it might be necessary for the publication  
> architecture to broadcast alerts, or something to that effect.
>
> Also, this apparently spans alerts pertaining to many subjects.  
> There is likely to be a need for a filter mechanism so that a  
> subscriber can identify the sorts of alerts of interest.
>
> In terms of "event state", I think there needs to be some  
> explanation of how the publication of an alert affects state within  
> the compositor, and how long the resulting state remains in effect.
>
> I wonder if an email based mechanism might not be better for this  
> sort of service.
>
I suspect this has the same scalability problems on the notification  
side of the equation.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Jul 2007 21:34:48 +0200

Hi Paul,

Paul Kyzivat wrote:
> architecture of the system in which this mechanism will be deployed. 
> It need not be normative, but could instead be part of a set of 
> requirements.
I agree.
> always geographically oriented, so the use of a per-geography target 
> for subscriptions seems to be more of an optimization. As Hannes noted 
I read through a paper by Henning published a few years ago and he 
investigated a similar architecture I described.
See http://www.cs.columbia.edu/IRT/papers/Schu0205_Providing.pdf

I am, however, open to different suggestions.
>
> Also, this apparently spans alerts pertaining to many subjects. There 
> is likely to be a need for a filter mechanism so that a subscriber can 
True. Filtering can happen in two places as part of
* LoST, and
* SUBSCRIBE

I could imagine both being used.

>
> In terms of "event state", I think there needs to be some explanation 
> of how the publication of an alert affects state within the 
> compositor, and how long the resulting state remains in effect.
OK

> I wonder if an email based mechanism might not be better for this sort 
There are, for sure, other ways to accomplish the same goal. The OGC, 
for example, has been working on GeoRSS. Carl Reed (our GEOPRIV-OGC 
contact person) promised me to send some slides for the Bar-BOF to 
provide more background info.

Ciao
Hannes

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Jul 2007 15:40:52 -0400

> I suspect this has the same scalability problems on the notification 

The scale of these notifications doesn't seem to be any larger than that 
we see employed constantly for spam. In effect this is just a sort of 
spam that perhaps should not be filtered out. And now that I think about 
it, perhaps it would be better to simply flood these messages just like 
spam, and let the recipients use spam filters to weed out the parts they 
don't want to receive.

Maybe not all spam is bad!

	Paul

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Jul 2007 21:54:47 +0200

Hi Dave,

>> I share the concerns of Jonathan and Dale.

That's fine. We are going to have a Bar-BOF and we are not going to 
submit documents for publication.

> very large, even for a single notification - perhaps O(10**7) for a 
Req-7 in draft-norreys-ecrit-authority2individuals-requirements-00.txt

> knowing who is listening for the notifications
Yep.

> - The authority is mostly interested in ensuring that those who wished 
> to be notified had a high probability of receiving the notifications.
Most likely.

> knowing who got the notifications and who did not
See requirement 8 in 
draft-norreys-ecrit-authority2individuals-requirements-00.txt

> also not very large, and likely has a slowly-changing schema.
Ok.

> likely to vary among the parties interested in receiving the 
Fine

> - Authorization of who is permitted to receive notifications is likely 
> to be loose (e.g. anyone) for most events.

Authorization for receiving a message has not been a high priority.

On the other hand, authorization for sending a message or on the 
receiver side for determining whether an alert is indeed from an 
authorized source has been of interest.

See Req-13 and Req-14 of 
draft-norreys-ecrit-authority2individuals-requirements-00.txt

> requirements of the class above.
I am not sure to what the authorization refers here.

> and technical tradeoff analysis?
In the reference section of the requirements document you can find more 
requirements by other SDOs.

> state maintenance and notification machinery is likely to just beg for 
> meltdowns and DoS attacks.
>
> under some key derived during authorization (to prevent leakage in the 
> case the information is sensitive).
The usage of multicast has been mentioned in context of this discussion 
and might indeed be interesting to investigate.

In this case I wonder why you wouldn't just use LoST to obtain the IP 
SSM address/port.

Regarding the content of the notifications: Do you consider the usage of 
CAP useful ?

>> for subscriptions seems to be more of an optimization. As Hannes 
>> noted somewhere in this thread, the relevant geographical area for a 
>> particular alert may span the areas of multiple notifiers. So it 
>> might be necessary for the publication architecture to broadcast 
>> alerts, or something to that effect.
>>
>> is likely to be a need for a filter mechanism so that a subscriber 
>> can identify the sorts of alerts of interest.
>>
You would still have to define two features:
* The sending side needs to know who would be interested in receiving 
alerts (and what type of alerts)
* The receiver still has to figure out who is responsible for sending 
alerts of a specific geographic region.

This leads to pretty much the same result.

Ciao
Hannes

---

From: "Xavier Marjou" <[email-masked]>
Date: Thu, 19 Jul 2007 00:12:00 +0200

> of service

As I understood the requirements, all available mechanisms should be
tried: email, SMS, and also SIP.

> Maybe not all spam is bad!

Yes: for this case, as SIP supports push mechanisms, why not take
advantage of it and directly push SIP MESSAGE (or INVITE) messages
towards user-agents of a given area? This would avoid the load of
SUBSCRIBE and NOTIFY messages vehicled in the netwok the whole year
round. (I understand that learning the location is the difficult point
in such a SIP push solution).

Note that an idea around the INVITE message could be to directly
perform a call to the users of a given area and to enforce an
automatic answer-mode (c.f.
http://www1.ietf.org/mail-archive/web/sip/current/msg12271.html ).
However, I finally found this solution too intrusive, as I easily
imagine that some people would for other purposes (e.g.: advertisement
...).

So my opinion is that investigating a SIP MESSAGE based mechanism
should be considered.

Xavier