Subject: Re: [sip-overload] A few comments on draft-shen-sipping-load-control-event-package-03

From: Charles Shen <[email-masked]>
Date: Thu, 4 Feb 2010 14:50:25 -0500

Eric, thanks for your review. Sorry for the late response due to
traveling. please see inline:

On Wed, Dec 23, 2009 at 11:19 AM, NOEL, ERIC C (ATTLABS) <[email-masked]> wrote:
> Charles,
>
> Do you think it is possible for the specifications in
> draft-shen-sipping-load-control-event-package-03 to actually trigger
> SUBSCRIBE/NOTIFY storms? Or is that already taken care in related RFCs?
>
> For instance, if as suggested in the introduction, User Agents actually
> subscribe to a notifier, in a carrier grade telecommunication network
> this has potential for scaling problems and "large numbers" of NOTIFYs
> could be broadcasted towards the edges. One suggestion would be to add
> text in your RFC to require staggering of SUBSCRIBE/NOTIFYs over "some"
> time period so as to prevent message storms.
>

In the UA -> Notifier direction, there should be natural spacing,
similar to when UAs are registering with their registrar in normal
cases. (in other words, this is not an avalanche restart)

In the Notifier -> UA direction, it seems there shouldn't be scaling
problems since notifications are sent to many different entities. Are
you talking about potential bandwidth issues between the notifier and
the edges? That seems not very likely either ...

> In Section 4.1, similar problem could occur when entities subscribe to a
> notifier "when certain events have occurred". I could imagine a case
> where following an earthquake all User Agents within the region are
> programmed to subscribe to a notifier, resulting in a SUBSCRIBE/NOTIFY
> storm. One suggestion would be to require some randomization over time
> in sending SUBSCRIBEs to notifiers so as to prevent message storms.
>

This example will indeed be somewhat like the avalanche restart
problem which is what our another draft
http://tools.ietf.org/html/draft-shen-sipping-avalanche-restart-overload-00
intends to address.

> Then, is it possible for one entity to subscribe to multiple notifiers?
> If so, should not there be provisions against conflicting NOTIFYs from
> different notifiers. For instance, one notifier requests subscriber not
> to send any outbound traffic, while another requests not sending any
> inbound traffic to the same subscriber. Not sure how to deal with such a
> problem without requiring entities to subscribe to no more than one
> notifier.
>

This looks like more an issue of mis-configuration or mis-calculation
(of rules) and seems to be orthogonal to the event package itself?

> In general, as protection against elements or signaling failures, you
> probably want to require NOTIFYs to be sent no earlier than xxx
> days/hours/minutes prior requested action. Similarly, you probably want
> to limit the NOTIFY requested action to be valid for no longer than yyy
> days/hours/minutes.

Mechanism-wise, there is the validity element that allows you to
specify when the action should be valid. I think the detailed timing
(days/hours/minutes) is then subject to the actual operator and
scenarios.

>
> There are a few typos, I assume ispell or equivalent will catch them
> (section 1 1st paragraph "sever", section 6.3.3 "...server depend on the
> type of of an initial...").
>

These should be fixed in the next update.

Thanks!

Charles

> Thanks,
>
> Eric
>
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload
>