Subject: RE: [Simple] 200 vs. 202

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 16 Nov 2001 23:45:31 -0500

After originally suggesting that we begin thinking about handling merging of
presence state at the subscriber, I am now going to back off of that
proposal. I fear that the complexities of forking SUBSCRIBE are simply too
great compared to the potential benefits, and Brian does a fine job here of
providing some good reasons. The simple fact that we have no real way to do
authentication (only works if the same number of proxies exists between
subscriber and watcher!!) is a clear hint that things are headed in the
wrong direction. Forking was meant for the case where you want to reach any
one of N things. Thats perfect for INVITE, but clearly it fails for the case
where you want to reach all things, as we seem to want here. Effectively,
the difference is between designing something that does reliable anycast
(which is not too hard) as compared to reliable multicast (which is still
largely an unsolved problem in the general case).  

So, I am proposing we revert to what is currently documented. You accept
only the NOTIFY that corresponds to the 2xx to the SUBSCRIBE, and thats it.
The recommendation stands to have a PA that aggregates whenever possible.

Now, some have pointed out that you cannot avoid forking because of all the
deployed proxies that already fork a SUBSCRIBE. However, the networks that
these are deployed in do not support presence. I think its reasonable for a
network designer that deploys presence to ensure that reasonable things
happen; i.e., there is a PA at known aggregation points. Now, if you have
users in an existing network that wish to use presence by placing a PA in
their clients, well, I would argue that in this case, all bets are off
regarding multiple clients. If you want multiple PA for a presentity, you
can't really do it unless your SIP provider deploys presence. I think thats
a reasonable thing.

Let us remember the importance of KISS as a design principle, and not try to
solve previously unsolved problems, as Brian points out.

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
  
-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 4:03 PM
To: Roy, Radhika R, ALCTA; Paul Kyzivat; [email-masked]
Cc: 'Robert Sparks'; 'James Undery'; Jonathan Rosenberg; 'Moran Tim
(NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'simple'
Subject: RE: [Simple] 200 vs. 202

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. 
... 
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: [email-masked]
Date: Mon, 19 Nov 2001 10:06:08 -0600

> From: Jonathan Rosenberg [mailto:[email-masked]]
>
> Forking was meant for the case where you 
> want to reach any
> where you want to reach all things, as we seem to want here. 

This is a very concise restatement of the primary argument
that I made when I proposed that we deprecate forking for
all non-INVITE requests.

SIP, as a working group, rejected this exact argument then (over my
objections). I fail to see why the situation would change now.

/a