ietf
[Top] [All Lists]

RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

2010-04-06 13:10:51
On Tue, 2010-04-06 at 13:39 -0400, Hadriel Kaplan wrote:

-----Original Message-----
From: Cullen Jennings [mailto:fluffy(_at_)cisco(_dot_)com]
Sent: Tuesday, April 06, 2010 12:56 PM
To: Hadriel Kaplan

No one has any empirical evidence or experience with what this thing
will do to large subscriber domains. (and by large I mean multiple
millions of UA's, which is the scale several SIP deployments are in now)

I'm aware of deployments with millions of UAs that use subscribe. Agree
there are growing points in scaling anything and everything


Right, but they're doing it for reg-events and presence, after the
Registration.  During an avalanche, for example, they're implicitly
throttled by the effective registration rates.  This config framework
is reversing it, having subscriptions before the registrations.  I'm
not saying it's not do-able or won't work, I'm just saying we don't
know. (and I'm saying it's not free, and some folks won't think it's
worth the cost)

This draft says nothing at all about the ordering of the change notice
subscription vs any registration.

If what we really want is something to force the UA to download a config
*right now*, then do that explicitly.  Give each registered UA a "private"
gruu, known only to the SSP and UA.  When you want to refresh the UA, send
a PUBLISH to the gruu, telling it to refresh its config.  You can do that
gruu statelessly on the SSP side, any number of ways.

I care more there is  a way to do it than how it is done but can you
explain how that is lighter weight than a subscribe? 

One way: when the UA Registers, have the Registrar construct a
"private" gruu, for example using a hash of the registered contact
with an unchanging key only known to the registrar. (so no extra state
in registrar)  Send that gruu back in the Register response with a new
param name defined in your spec.  The UA stores this private gruu, but
cannot use it for anything but matching.  The SSP can send an
out-of-dialog PUBLISH asynchronously, to that contact using the gruu,
to tell the UA to go get the HTTP config again.

It's lighter weight because there's no subscription messaging, no
permanent dialog state, and even the gruu is constructable and does
not need to be stored by the SSP, only by the UA.
[sarcasm=on] I don't know why the IETF keeps trying to put state into
the middle instead of leaving it in the ends! :) [sarcasm=off]

I'd be open to a fully worked out proposal based on PUBLISH, but I
actually don't think that there are big savings over a SUBSCRIBE based
mechanism.   I don't buy the argument that the dialog state is
burdensome - it's a few hundred bytes at most (and much of that size is
under the control of the server).

I do have some problem with making the notification some kind of side
effect of the 'normal' registration.  REGISTER exists to map an AOR to
one or more Contacts.  The Configuration Service needs to be able to
address the change notice (whatever method carries it) to a specific UA,
_not_ to the AOR of some user registered to that UA.  If the UA is going
to REGISTER an AOR for itself that is distinct from that of any user
registered on it, then the whole thing starts to look a lot like a
SUBSCRIBE.   While we did not include text in the draft to suggest the
use of the SIP-Etag mechanism in draft-ietf-sipcore-subnot-etags, it
could be added to suppress the initial NOTIFY associated with the
subscription (and if it would help, I'd have no problem with putting
such text in).


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>