On Apr 6, 2010, at 16:47 , Bernard Aboba wrote:
Hadriel Kaplan said:
“Howdy,
This may not be within the normal rules of etiquette, but I will re-iterate
my issues with this draft which I raised when it was discussed in RAI.
1) The mechanism does not scale, for large SSP's. (is this only meant for
small deployments?)
Expecting every UA to keep a permanent SIP Subscription to "config change"
servers is unreasonable. Either the UA makes this Subscription directly to
the Server(s), in which case there will be a large volume of keep-alives just
to keep NAT pinholes alive; or it makes it through edge proxies, in which
case it's a lot of SIP messaging both in the sense of keeping the Subscribe
dialog alive but more importantly at the worst possible time: during
avalanche restarts. Either way, it's not good.
All this state and signaling is to achieve what? So that once a year or so we
can tell UA's to do another HTTP Get so they change one of their config
settings, or upgrade their firmware?? How is that cost-burden justified? Do
most other applications keep permanent connections for such changes? Not as
far as I can tell. They poll on a (very) infrequent interval.
2) I would be ok with (1) if it was optional, so only providers that wanted
it had to pay for it, but as far as I can tell the mechanism *requires*
implementation of this SIP Subscription service. Maybe I'm reading it wrong?
Section 2.5.1 says the HTTP response MUST have the Link header, with a SIP
URI, and if the Subscription attempt fails then it has to start again, etc.
Seems to me you're requiring/mandating a "nice-to-have-feature", and an
expensive and complicated one at that. Why?
-hadriel ”
[BA] I agree with your assessment. This is one of those situations where
(infrequent) polling scales better. That is how currently most OS update
mechanisms work; they poll the update servers at intervals orders of
magnitude longer than NAT refresh times (e.g. weekly or daily at most), with
randomized polling times. That way there is no need to maintain NAT
bindings, and no danger of “flash crowds”. Yes, it might take a while to
bring all the clients up to the latest version, but if you’ve got any
substantial client population, then you need to spread out the updates anyway
to control the load on the update servers.
So there are somethings like upgrading the software firmware on phones where a
slow roll over makes sense, however there are other things like moving from a 4
digit to 5 digit internal dialing plan where you want to flash cut over all the
phones at a given site. Can you imagine telling a site, uh, your phone will
switch from 4 to 5 digit dialing some time in the next few days - if 4 digit
stops working, try 5 digits and see if that works. That the sort of think that
generates support calls that are far more expensive than servers. I realize
that if you put the poll rate low enough, polling can achieve the same as
notification but the rates required for many services make notification scale
better than polling.
In my experience, even where NOTIFY is used to provide update notifications
today, SUBSCRIBE is not. Yes, that is non-standard, but I think it
demonstrates concern about the overhead relating to SIP subscription/refresh.
__
Having dealt with many or the problems that come from setting MWI lights using
NOTIFY without subscribe I am fairly confident that this NOTify without
SUBscribe is broken is some many ways it is not even worth discussing.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf