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 [email protected] https://www.ietf.org/mailman/listinfo/ietf
