Subject: RE: [Simple] 200 vs. 202

From: "Brian Stucker" <[email-masked]>
Date: Tue, 13 Nov 2001 15:02:39 -0600

Radhika,

I am suggesting this simplified approach, and I have done so a number of
times before for various reasons. It solves a lot of problems in one fell
swoop in my mind, and isn't giving up a whole lot in the process. Arguing
the differences in the way forking for INVITE differs from SUBSCRIBE/NOTIFY
doesn't seem all that productive to me, because it's comparing apples to
oranges, and any solutions suggested by doing so lead to mechanisms that
would cause us to have to essentially create SIP/2.1 to handle, or are so
awkward that the medicene is arguably worse than the disease.

INVITE is not an isomorphic request, and ACK has caused headaches for
implementors as well. Ask anyone working on early media what the three-way
handshake model that INVITE has done to the complexity of what is otherwise
a very straight-forward message sequence. How many drafts are out there
because of that little interaction alone?

The solution to have one, and only one, PA, is related to the forking
problem, yes, but so much more:

- Many other implementations that have MILLIONS of subscribers have turned
to allowing only 1 PA to solve this problem, is obviously sufficient to meet
customer expectations. 

- Go out and look at the billing models for these IM services that have
client-controlled topologies. They can't. If the clients can be their own
presence agent, then it makes it next to impossible to charge them for that
service. All you can do is charge for connectivity, and that's it. 

- It's really hard to build presence based services in the network (like
network based call screening) unless you provision the client with
potentially a great deal of information about the provider network, and
expect the customer to leave their device on 24x7.

Having more than one presence user agent for a presence agent makes perfect
sense. It's a huge advantage that SIMPLE has over the other IM presence
implementations out there today. Further decomposition, however, doesn't
really add anything unless it is your desire to have a network full of
extremely intelligent clients that are always on, and have flat-rate
high-speed access to the network 24x7.

To answer your second question, let's say that's what we want. On top of all
the trouble we have to go through to synchronize a single presence agent
finite state machine with the FSM's of all the watchers, let's make things
that much more interesting, introduce a plethora of race conditions and
error scenarios, and try synchronizing a fully connected graph of N number
of presence agent FSM's to M number of watchers. 

Even if it were possible to sufficiently squash all of the race conditions
and error scenarios, aren't we really pushing it a little too far to try to
do so? Presence and SUBSCRIBE/NOTIFY is already the near perfect
denial-of-service attack due to the messaging demands it can place on a
network. Why inflict N * M number of messages, when you can do perfectly
well, offer more services more reliably with lower demand on the end user,
probably at a cheaper price (because the terminals don't have to be as
fancy, and OA&M operations are centralized), and have 1 * M number of
messages.

Thoughts?

Brian Stucker
Nortel Networks

-----Original Message-----
From: Roy, Radhika R, ALCTA [mailto:[email-masked]]

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]

If we leave the stake in the ground that presence information should not be
aggregated at the watcher, because policy is difficult at best to apply in
this situation, then we need to ensure one of two things:

- Making sure that there is one, and only one, PA (which is what ICQ, AOL,
MSN, etc. have been doing for a long time now).
[Roy, Radhika R, ALARC]  Are you suggesting this simplified solution
because, as Paul has pointed out, there is a fundamental difference the way
forking works in INVITE and SUBSCRIBE/NOTIFY method? Is this solution due to
the forking problems (not to be satisfactorily addressed in SUBSCRIBE/NOTIFY
method)?

- Making sure that if there is going to be more than one PA, either the
results are always aggregated somewhere in the network (for policy
decisions) or that all of the PA's are kept in sync (which is extremely
difficult to do).
[Roy, Radhika R, ALARC]  This is what the end results may look like. I
wonder how can we communicate among multiple PAs to synchronize states? We
may need to change the forking behavior in SUBSCRIBE/NOTIFY if the present
suggested method is not satisfactory.

...