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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf