Re: [Simple] WGLC: http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-03.txt

Peter Saint-Andre <stpeter@stpeter.im> Wed, 16 January 2008 23:19 UTC

Return-path: <simple-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFHXD-0002BO-6i; Wed, 16 Jan 2008 18:19:03 -0500
Received: from simple by megatron.ietf.org with local (Exim 4.43) id 1JFHXC-0002BF-Bo for simple-confirm+ok@megatron.ietf.org; Wed, 16 Jan 2008 18:19:02 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFHXB-0002B5-Vi for simple@ietf.org; Wed, 16 Jan 2008 18:19:02 -0500
Received: from dizzyd.com ([207.210.219.225]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFHXB-0004WT-5R for simple@ietf.org; Wed, 16 Jan 2008 18:19:01 -0500
Received: from wrk225.corp.jabber.com (dencfw1.jabber.com [207.182.164.5]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTP id E0898404A0 for <simple@ietf.org>; Wed, 16 Jan 2008 16:18:59 -0700 (MST)
Message-ID: <478E90E2.3020802@stpeter.im>
Date: Wed, 16 Jan 2008 16:18:58 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: simple@ietf.org
Subject: Re: [Simple] WGLC: http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-03.txt
References: <DD00CC52-C0B2-46A4-979D-BEA0C2491274@estacado.net>
In-Reply-To: <DD00CC52-C0B2-46A4-979D-BEA0C2491274@estacado.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions <simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1400999043=="
Errors-To: simple-bounces@ietf.org

Robert Sparks wrote:
> This is a SIMPLE Working Group Last Call for Comments on
> http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-03.txt
> 
> Please review this draft carefully. Provide comments to the editor 
> and/or the list no later than
> Monday 21 January 2008.

I think this draft needs further work before it is ready for IETF Last 
Call. As a point of comparison, I have just updated a similar analysis 
for XMPP:

http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-presence-analysis-03.txt

Herewith some comments.

1. As I previously expressed on this list, I think it is not a good idea 
to compare two different technologies in such a document. Therefore I 
have removed any mention of SIP presence from the XMPP analysis (other 
than to point to draft-ietf-simple-interdomain-scaling-analysis from my 
I-D), and I suggest that the authors of the SIP/SIMPLE analysis do the 
same. There are just too many differing assumptions and possible 
scenarios to accurately compare two presence technologies in a single 
document (let alone more than two technologies). Therefore I strongly 
suggest the following:

1a. Modify the second paragraph of Section 1 ("Introduction") to remove 
references to other presence technologies.

1b. Remove Section 2.10 ("Other Protocols"). In particular, the 
calculations in this section use SIP terminology, which patently does 
not apply to non-SIP systems.

1c. Remove the fourth bullet-point in Section 7 ("Conclusions"). In 
particular, during discussion on this list the claims in this paragraph 
were shown to be seriously misleading or false.

1d. In several places the analysis claims to apply not just to 
SIP/SIMPLE presence systems but to presence systems built using any 
possible presence technology. Extreme care should be taken when making 
such statements.

2. While working on the XMPP presence analysis just now, I attempted to 
incorporate the fact that the number of users who are registered with a 
presence service is typically much greater than the number of users who 
have an active presence session with the service. In my experience 
helping to run a fairly large (~300,000 user) consumer-oriented presence 
and messaging service, typically at most 5% of the users are "online" at 
any one time. The number of online users within an enterprise deployment 
is typically higher, on the order or 40% online. To be conservative, in 
the XMPP analysis I have assumed that 10% of the users at a service 
provider deployment are online at any one time and that 50% of the users 
at an enterprise deployment are online at any one time. I do not see 
that this factor has been taken into account in the SIP/SIMPLE analysis 
(though perhaps I am missing something). I think it is extremely 
important to take the registered vs. online factor into account because 
this is the usage pattern that presence systems experience in the real 
world and those who read these presence analyses will quickly be scared 
off if we don't do so (they will just look at the number of users and 
assume that is the number of concurrent presence sessions).

3. The real-world numbers in Section 2.2 ("Assumptions") are helpful, 
but they are incomplete:

3a. What are the numbers of registered users and concurrent users for 
the "large consumer network"?

3b. Are the 110 users (consumer network) and 200 users (enterprise) in 
the watch list total users or federated users? Only the number of 
federated users is important for this analysis.

3c. Why is the peak number of instant messages mentioned for the 
consumer network? This analysis deals only with presence.

3d. It is mentioned that about 50% of the enterprise users are online at 
any one time. What percentage of the users at the consumer network are 
online at any one time? And (as mentioned) is this kind of percentage 
factored into the calculations?

4. The inclusion of full vs. partial notifies, dialog optimizations, 
NOTIFY optimizations, and so on makes the calculations very involved and 
confusing to read (e.g., I have not yet had time to review them all in 
detail). Can they be simplified somehow?

5. I think it might help to make the scenarios a bit more realistic, at 
least by explaining how a particular scenario might apply in the real 
world (e.g., "this scenario is similar to what might be observed in the 
context of federation between two large service providers"). I have 
tried to do that in version -03 of the XMPP analysis, but we could even 
go farther.

6. When I attempted to address the issue of real-world relevance, I 
found that several of the scenarios in the XMPP analysis diverged from 
the scenarios in the SIP analysis. I would be happy to work directly 
with the authors of draft-ietf-simple-interdomain-scaling-analysis to 
sync up on the scenarios.

That's it for now.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple