Subject: [Sipping] comments on draft-houri-sipping-presence-scaling-requirements-00

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Jul 2007 13:43:07 -0400

Thanks for continuing to drive forward on this SIMPLE/SIP event 
optimization work. I think this is a hugely important area for SIMPLE 
and I support going forward here.

My main comment is that the document might benefit from inclusion of 
some of the conclusions that one can draw from your interdomain scaling 
analysis. In particular, the document describes requirements for a 
solution but doesn't say much about the problem beyond, "improve scale". 
I think it would benefit from a picture that shows the peering model you 
are worried about, and talks about some of the challenges in scaling:

   a. the large number of notifies between domains that are redundant 
because they carry the same data
   b. extra, somewhat useless notifies due to things like refreshes
   c. dialog management costs

I think its important to separate out the things we CAN fix, from things 
that are fundamental. There is, at the end of the day, a minimum set of 
messages that need to flow that no protocol can ever do better than, 
from an information theory point of view. This document should list what 
those are, that need to be addressed. The above three are my top 3.

> We should also consider whether using the same protocol between
>    clients and servers and between servers is a good choice with this
>    problem?  It may be that in interdomain or even between servers in
>    the same domain (as between RLSs and presence servers) there is a
>    need to have a different protocol that will be very optimized for the
>    load and can assume some assumptions about the network (e.g. do not
>    use unreliable protocol as UDP but only TCP).

I think this is a very likely path. Its not a new one either; as you 
say, RLS is already doing something like this.

>  Another issue that is more concerning protocol design is whether
>    NOTIFY messages should not be considered as media as the audio, video
>    and even text messaging are considered?  The SUBSCRIBE can be
>    extended to do similar three way handshake as INVITE and negotiate
>    where the notify messages should go, rate and other parameters.  This
>    way the load can be offloaded to specialized NOTIFY "relays" thus not
>    loading the control path of SIP.

This is something we considered way, way back in the original design of 
SIMPLE. It got discarded quickly since it was too different from how 
folks were thinking about presence, would make building gateways harder, 
and so on. I think it merits consideration. It certainly won't save 
bandwidth between domains (that'll go up with this proposal). It saves 
servers from processing notifies before they get sent to the watchers 
(though, there was probably little processing to begin with), but at the 
cost of a lot more notifies that the other proxy server has to send.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Qian Sun <[email-masked]>
Date: Wed, 18 Jul 2007 16:21:16 +0800

Hi,

In presence system a user may have 100 buddies. But for most of these buddies, this user just wants to know whether they are online or offline (basic presence info). He doesn't care about their mood or activities etc. (rich presence info, maybe more and more presence info extensions will be made in the future).

The basic presence info is very small size, and doesn't change very fast. If there was only basic presence info in the system, we need not to worry about traffic or scaling problem. 

We can have some pure client side optimizations to cut down the information which the users don't need. E.g., when the presence client starts, it should subscribe to the basic presence info of all the buddies. If the user wants to see a special guy's rich info, he can change the filter.

Cheers,
Qian

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Saturday, July 14, 2007 1:43 AM
To: IETF Sipping List
Subject: [Sipping] comments ondraft-houri-sipping-presence-scaling-requirements-00

-Jonathan R.

---

From: Avshalom Houri <[email-masked]>
Date: Wed, 25 Jul 2007 21:40:16 +0300

Thanks for your comments. Sorry for the late reply.

more Inline

> are worried about, and talks about some of the challenges in scaling:

Agree.

> those are, that need to be addressed. The above three are my top 3.

I think that we should fix what we can but I am concerned that we need to 
think
about different ways to implement presence in order to get to real large
numbers. As people suggested not every user needs to get notification on 
every
user all the time. I tried to get to a minimal model in the scalability 
analysis
when talking about other protocols but I guess that this should be made 
more explicit.

> cost of a lot more notifies that the other proxy server has to send.

It will not save bandwidth but it can give a lot of room for novel design
that can do a lot of optimizations. It may be (not sure) that the work on 
MSRP
have changed the attitude a bit so having a relay for the actual NOTIFY 
messages
will not be looked at something that is not acceptable.