Subject: RE: [Simple] 200 vs. 202

From: "Brian Stucker" <[email-masked]>
Date: Tue, 20 Nov 2001 09:26:04 -0600

There are two major problems, as I see it, and some other, minor problems
(two of which you've pointed out). I think I've outlined these before, but
I'll do so again.

Jonathan has pointed out probably the biggest problem of all, the matter of
applying policy. It needs to be at a location that the watcher does not have
any control over, or visibility into otherwise the value of changing
presence information based on policy is really lost. This requires someone,
somewhere in the picture, who is not the watcher, to apply policy, and do so
in a consistient manner. This means that at the very least, a PA or PAs
somewhere have to apply policy. Which leads me to my next major problem...

All of presence can be viewed as nothing more than synchronizing two finite
state machines. Very straightforward. Anything that has a definite set of
states can be viewed this way. In order to apply policy at several PAs prior
to having them send their revised presence document to the watcher, all of
the PAs version of what the policy should be needs to be synchronized. That
means that they all need to have a way of keeping them synchronized, and
SUB/NOT is a mechanism for doing so. In order to ensure that all of the
presentity's presence documents (revised or otherwise) makes it to the
watcher in a consistient manner, the PAs also have to watch each other's
presence as well. Synchronizing 2 state machines is pretty easy, which is
what a single SUB/NOT dialogue sets up. Synchronizing N state machines is
very tough. With two FSM's, synchronization is done in a uni-directional,
lock-step manner. With N FSM's synchronization is done in a multi-way
manner. This is much more difficult:

- Glare: You run into problems where you get two different states for the
same resource at a given PA, and must figure out which one is the correct
one to take. Simply taking the first one, or the last one isn't good enough.
Since we have no common clocking source, there's no way of knowing which one
is the correct presence tuple to use. The closest solution to this is to
count how many hops each presence tuple has taken, and always take the one
closest to the source. However, since we're not guaranteed to be able to
even contact all of the PAs at any given time, this may wind up being
problematic. You may be stuck using presence tuple data that has traveled
over several hops, getting kludged up along the way.
- Race Conditions: Two or more given presence tuples change, but the changes
have only propagated half-way through the set of presence agents. Since any
change should trigger a notification, the watcher will see presence tuple
states "flutter" all over before (hopefully) settling down to the correct
state. If the PAs are all watching one another, and the watcher is watching
all of the PAs, then it should always (in theory) settle on the correct
state, but could be in incorrect intermediate states for a noticible period
of time.
- Complete Knowledge of State: In a 2 FSM synchronization scenario, knowing
the complete state picture is simple. You are given it by the master FSM,
and you're done. In the N-way FSM synch scenario, you have to know the state
of N FSM's. However, we do not have a reliable mechanism for ensuring that
this happens (thus the thread on forking began once again).

I could go into more detail on some of the other problems, but this is a
good start in my view. As Jonathan points out, who is screaming for there to
be multiple PAs in the first place? We can obviously do very well with a
single presence agent because this is how every major *widely deployed*
presence model works, and people don't seem to mind at all.

Regards,

Brian Stucker
Nortel Networks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 19, 2001 6:04 PM
To: Stucker, Brian [NGB:B635:EXCH]; adam.roach; 'Jonathan Rosenberg';
Roy, Radhika R, ALCTA; Paul Kyzivat
Cc: Robert Sparks; 'James Undery'; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai
(c)'; 'Brazier Lachlan'; 'simple'
Subject: RE: [Simple] 200 vs. 202

Part 2... note that I'm addressing multiple presence sources
specifically here, **not** the general SUB/NOT forking problem
(that was my previous mail).

Perhaps I'm being daft, but I can't see what is so complicated
about merging state received from two different sources,
GIVEN THE WAY THE CPIM PRESENCE FORMAT IS DEFINED.

I've put those nine words in all-caps because they are crucial
to understanding what I'm trying to say.

For presence, the state information delivered by a
concentration point in the network will contain the state of
several different entities. This differs in no real way (in terms
of forming a single coherent state to be rendered to the user)
from the situation in which you receive this state directly from
each entity.

I've given it a bit of thought, and (for presence, at least), can
really see only two open issues if we allow multiple PUAs to be
established by an initial SUBSCRIBE:

- How do we ensure that the presentity ID is unique? (We could fix
  this by requiring GUIDs or similar), and

- How do we make sure that we don't get information about a particular
  presentity from more than one source (e.g. an endpoint PUA and a
  concentrator) -- or, if you do (and they are in conflict), how do
  you sort out which is authoritative? The answer to this isn't as trivial,
  but I can think of several easy-to-implement schemes that would make
  this work out just fine.

Neither of these are showstoppers. The first one isn't even difficult.

That said, there have been several intelligent people on this list
insisting that there are hordes of intractable problems that prohibit
merging state at the subscriber end, so I must be overlooking something
massive. It would be instructive -- and probably more conducive to
progress -- if people would argue their points in specific terms (such
as detailing individual problems, like the two I describe above) instead
of just calling the entire problem set "difficult" and throwing their
hands up.

/a

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Monday, November 19, 2001 5:35 PM
To: adam.roach; 'Jonathan Rosenberg'; Roy, Radhika R, ALCTA; Paul Kyzivat
Cc: Robert Sparks; 'James Undery'; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)';
'Brazier Lachlan'; 'simple'
Subject: RE: [Simple] 200 vs. 202

Adam,
I respect your viewpoint and the work in the event draft, but I'm going to
have
to disagree with you.
Option 1 makes the assumption that sometimes reach-all is valid, and
sometimes
it's not. It's flexible. If you want to pay attention to an apparently
unsolicited NOTIFY that matches everything except the TO tag from the 200 OK
from the SUBSCRIBE, go for it. If not, then you've got a problem, squelch
the
messages you don't want with the 481.
Option 2 is overkill. It might not matter to the particular service or
mechanism being deployed if the forking behavior of non-INVITE messages is
going to pose a problem. Not allowing forking would be (to me) like forcing
everything to use TCP instead of UDP. Plus, it's SIP/2.1.
Option 3 assumes that the problem of having multiple dialogs created as part
of
presence is a good thing to have in the first place. And it's SIP/2.1.
My argument all along has been that even if the forking issues are resolved,
there's fundamental problems with allowing multiple subscriptions to be
created, in the case of presence. That because of this, for presence, it is
best to very strongly recommend that only one presence agent be in the
network
at any point at time. It would not matter if forking worked exactly how
everyone wanted it to work or not, you'd still have serious problems.
Option 1 works for presence as far as I can see, and does not place or pose
any
restrictions on others who, for their event package, want to loosen up the
rules a bit more. It is a client problem entirely. The network won't even
know
what is going on or care.
Am I missing something?
Regards,
Brian Stucker