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

From: "NOEL, ERIC C (ATTLABS)" <[email-masked]>
Date: Wed, 23 Dec 2009 11:19:06 -0500

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 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.

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.

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.  

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...").

Thanks,

Eric

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 29 Dec 2009 11:26:20 -0500

I agree that it is important to make sure that any mechanism for 
addressing congestion does not, of itself, significantly exacerbate the 
congestion.

Janet

[email-masked] wrote on 12/23/2009 11:19:06 AM:

> [image removed] 
> 
> [sip-overload] A few comments on draft-shen-sipping-load-control-
> event-package-03
> 
> NOEL, ERIC C (ATTLABS) 
> 
> to:
> 
> sip-overload
> 
> 12/23/2009 11:19 AM
> 
> Sent by:
> 
> [email-masked]
> 
> Charles,
> 
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload