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