Subject: [Simple] I-D Action:draft-ietf-simple-interdomain-scaling-analysis-03.txt

From: [email-masked]
Date: Sun, 18 Nov 2007 04:40:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title           : Presence Interdomain Scaling Analysis for SIP/SIMPLE
	Author(s)       : A. Houri, et al.
	Filename        : draft-ietf-simple-interdomain-scaling-analysis-03.txt
	Pages           : 59
	Date            : 2007-11-18

The document analyzes the traffic that is generated due to presence
subscriptions between domains.  It is shown that the amount of
traffic can be extremely big.  In addition to the very large traffic
the document also analyzes the affects of a large presence system on
the memory footprint and the CPU load.  Current approved and in work
optimizations to the SIMPLE protocol are analyzed with the possible
impact on the load.  Separate documents contain the requirements for
optimizations and suggestions for new optimizations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-03.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-simple-interdomain-scaling-analysis-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-03.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Joe Hildebrand" <[email-masked]>
Date: Tue, 20 Nov 2007 11:39:04 -0700

> -     Comparing to protocols that do not have the overhead of SIP (e.g.
>       XMPP) shows that the number of messages is less by about a half.
>       The number of bytes is also reduced by about a half.  It is
>       interesting to see that when the presence document is big (3000
>       bytes) and partial and notify optimizations are applied, the
>       number of bytes is smaller in SIP!

I'm sorry, but I just don't see how this last sentence could be true.  I was going to write a more detailed response, but see that Dave Cridland already did here on 10/4:

http://urltea.com/254t

Either the work should be shown that leads to this statement, or it should be removed.

-- 
Joe Hildebrand

---

From: Avshalom Houri <[email-masked]>
Date: Tue, 20 Nov 2007 23:30:34 +0200

Joe,

Did you look at the numbers in section at section 2.10 at the draft? Note
that the claimed comparison was made for 3K message while using partial
notifies.

Maybe I should not have said "e.g. XMPP" since in XMPP you can claim that
you will never use such a big presence document due to the use of getting
other parts of the presence document via other ways like PEP.

However, it seems to me that at the end of a day data is data, it does not
really matter if you are going to get it from the server of via other 
ways.

--Avshalom

"Joe Hildebrand" <[email-masked]> 
20/11/2007 20:39

To
<[email-masked]>
cc

Subject
RE: [Simple] 
I-DAction:draft-ietf-simple-interdomain-scaling-analysis-03.txt

>       number of bytes is smaller in SIP!

I'm sorry, but I just don't see how this last sentence could be true.  I 
was going to write a more detailed response, but see that Dave Cridland 
already did here on 10/4:

http://urltea.com/254t

Either the work should be shown that leads to this statement, or it should 
be removed.

-- 
Joe Hildebrand

---

From: "Joe Hildebrand" <[email-masked]>
Date: Tue, 20 Nov 2007 15:07:15 -0700

> Did you look at the numbers in section at section 2.10 at the 
> draft? Note that the claimed comparison was made for 3K 
> message while using partial notifies. 

Yes.  I'm saying that XMPP effectively always uses partial notifies, so we won't have 3k messages, even with 3k of presence data.

> Maybe I should not have said "e.g. XMPP" since in XMPP you 
> can claim that you will never use such a big presence 
> document due to the use of getting other parts of the 
> presence document via other ways like PEP. 

If you have another presence protocol in mind, like IMPS/WV, I don't have any objection to changing the e.g.

> However, it seems to me that at the end of a day data is 
> data, it does not really matter if you are going to get it 
> from the server of via other ways. 

It's a question of how often you get which subset of the data.  If you get a small subset of the data, only when it changes, rather than a full document for any change, it has a large impact on bandwidth.  This is the same reason that partial-notify exists.  

Even with the caveat that in XMPP you have to transmit the entire PEP item (a collection of related data, rather than just the changed element), the overhead of the SIP headers will almost always be greater than the item overhead, since PEP items tend to be very small.

-- 
Joe Hildebrand