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

From: Robert Sparks <[email-masked]>
Date: Mon, 7 Jan 2008 13:13:05 -0600

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.

Thanks,

RjS

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 16 Jan 2008 16:18:58 -0700

Robert Sparks wrote:
> http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-03.txt
> 

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/

---

From: "Vikas Tandon" <[email-masked]>
Date: Thu, 17 Jan 2008 10:52:38 +0530

unsubscribe

<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>Confidentiality</title>
<style>
<!--
P {
	FONT-FAMILY: arial,sans-serif
}
-->
</style>
</head>

<body>

<p><font face="Arial" color="#C0C0C0" size="1">
		<span lang="EN-US" style="font-style:italic">
		Confidentiality: Information transmitted by this EMAIL is proprietary of
		<u><b>ORG GROUP</b></u>&nbsp;and is intended for use only by the individual or entity to 
		which it is addressed and may contain information that is privileged, 
		confidential, or exempt from disclosure under applicable law. If you are 
		not the intended recipient of this EMAIL immediately notify the sender 
		and delete the Email including attachments, if any. For further 
		information about ORG please see our website at 
		</span></font>
		<font face="Arial" color="blue" size="1">
		<span lang="EN-US" style="COLOR: blue; font-style:italic">
		<a href="http://www.orgltd.com/"><font color="#C0C0C0">http://www.orgltd.com/</font></a></span></font></p>
		<hr>
<p>&nbsp;</p>

</body>

</html>