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
- [Simple] WGLC: http://www.ietf.org/internet-draft… Robert Sparks
- Re: [Simple] WGLC: http://www.ietf.org/internet-d… Peter Saint-Andre
- [Simple] unsubscribe Vikas Tandon
- Re: [Simple] WGLC: http://www.ietf.org/internet-d… Avshalom Houri
- Re: [Simple] WGLC: http://www.ietf.org/internet-d… Peter Saint-Andre