Subject: [Simple] [Fwd: I-D Action:draft-saintandre-xmpp-presence-analysis-01.txt]

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 02 Oct 2007 11:24:49 -0600

FYI

-------- Original Message --------

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Interdomain Presence Scaling Analysis for the
Extensible Messaging and Presence Protocol (XMPP)
	Author(s)       : P. Saint-Andre
	Filename        : draft-saintandre-xmpp-presence-analysis-01.txt
	Pages           : 17
	Date            : 2007-10-02

This document analyzes the scalability of presence sharing between
domains that federate using the Extensible Messaging and Presence
Protocol (XMPP).  This analysis is provided as a source of comparison
with a similar analysis being performed regarding the presence
extensions to the Session Initiation Protocol (SIP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-presence-analysis-01.txt

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

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 4 Oct 2007 10:46:00 -0400

Henry pointed me to this document.

I had a quick read, and said to myself "how could we be so stupid?"

Then I read it again.

The key part is this:

   [PROBLEM] assumes that presence notification packets will typically
   be on the order of 3.5 kilobytes in size (not including TCP or UDP
   overhead).  XMPP presence notification packets tend to be much
   smaller than SIP presence notification packets; in this document we
   assume (based on deployment experience) that they are typically 200
   bytes in size for basic on-off presence.  However, some XMPP
   applications may include additional information in a presence
   notification packet, such as entity capabilities as described in
   [XEP-0115].

[PROBLEM] is the scaling analysis paper,
draft-ietf-simple-interdomain-scaling-analysis-01.txt

It says:
   o  (C11) Size of an average presence document.  The size is assumed
      to be 3000 bytes based on sizes from examples in RFCs.  Note that
      assuming 3000 bytes for presence document is relatively modest if
      we take into account multiple devices and location information.
      When there will be multiple presentities in the same NOTIFY as in
      the initial NOTIFY for a resource list [10] or there is less
      information in the presence document due to partial notifications
      these factors will be taken into account.

Back to Peter's paper:
   User's server sends updated presence to contact (160 bytes):

   <presence
       from=[email-masked]/balcony'
       to=[email-masked]/orchard'
       xml:lang='en'>
     <show>xa</show>
     <status>bbiab</status>
     <priority>0</priority>
   </presence>

And then he goes on assuming this 160 byte message should be compared to 3K
   o  (C09) Presence notification size in bytes -- 200 bytes.
   o  (C10) Presence notification ack size in bytes -- does not apply
      since XMPP presence notifications are not acked.
   o  (C11) Presence document size in bytes -- does not apply since XMPP
      presence notifications do not include presence documents.

   BOTTOM LINE
   (B01) Total number and bytes per presence session
               Number .................................... 3,360,000
               Bytes  .................................. 640,000,000

Where [PROBLEM] says:
   (C09) NOTIFY message size not including presence doc........500
   (C10) 200 OK for NOTIFY message size in bytes...............370
   (C11) Size of an average presence document................3,000
   ** Bottom Line
   (B01) Total number of message & bytes during the day
             Number of msgs.............................12,800,000
             Bytes..................................49,756,800,000

But hang on.

If ALL you send is basic presence, the NOTIFY would be something like:
     NOTIFY sip:[email-masked] SIP/2.0
      Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk
      From: <sip:[email-masked]>;tag=ffd2
      To: <sip:[email-masked]>;tag=xfg9
      Call-ID: [email-masked]
      Event: presence
      Subscription-State: active;expires=599
      Max-Forwards: 70
      CSeq: 8775 NOTIFY
      Contact: sip:server.example.com
      Content-Type: application/cpim-pidf+xml
      Content-Length: ..
    <?xml version="1.0" encoding="UTF-8"?>
   <impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf"
       entity="pres:[email-masked]">
     <impp:tuple id="sg89ae">
       <impp:status>
         <impp:basic>open</impp:basic>
       </impp:status>
       <impp:contact priority="0.8">tel:+09012345678</impp:contact>
     </impp:tuple>
   </impp:presence>

So, indeed, xmpp's 160 bytes is smaller than SIP's 850 bytes, but if you
expand the presence document to send more stuff, which is what a typical
presence system would do, the SIP overhead would become a smaller percentage
of the total message size and it would seem they would get a whole lot
closer to the same number of bytes.

The number of messages is a little closer to the truth because:
1. xmpp is TCP only, and doesn't need an ACK
2. xmpp doesn't refresh subscriptions

The latter, if you want apples to apples, is solved by setting the refresh
period to be very large.  Not something I think is a good idea, but if you
can live with no refresh, go right ahead.  The former is something we live
with, because we need to be able to run over UDP.

So, while xmpp is somewhat more efficient, it's nowhere near the difference
claimed in the Peter's paper.

Whew.  I don't feel so stupid after all.

Brian

> -----Original Message-----
> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Tuesday, October 02, 2007 1:25 PM
> To: [email-masked]
> Subject: [Simple] [Fwd: I-DAction:draft-saintandre-xmpp-presence-analysis-
> 01.txt]
> 
> FYI
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 04 Oct 2007 10:08:13 -0600

> Henry pointed me to this document.

Thanks for the feedback. Let's get this right!

> I had a quick read, and said to myself "how could we be so stupid?"

It's not about stupidity. Everyone who has worked on these technologies
is fairly intelligent as far as I can tell. :) It's a question of
technology performance.

>       these factors will be taken into account.

Right. I have not yet had time to dig deeply into the question of
whether draft-ietf-simple-interdomain-scaling-analysis-01 (hereafter
"the SIP analysis") correctly reflects the state of SIP/SIMPLE
technologies as developed and deployed on the Internet today. Given that
I am not a SIP expert, I operated on the assumption that the SIP
analysis is accurate. If that is not so, then I will release an updated
XMPP analysis once the SIP analysis has been corrected.

>        <impp:contact priority="0.8">tel:+09012345678</impp:contact>

It sounds as if the SIP analysis is perhaps not correct. If that is the
case, I look forward to version -02 of the draft so that I can use the
correct numbers in the XMPP analysis. The 3k estimate seemed high to me,
but I'm not a SIP expert.

> claimed in the Peter's paper.

Again, I look forward to version -02 of the SIP analysis. I certainly
want to make sure that we compare apples to apples.

Furthermore, as I noted in my analysis, real-world numbers from deployed
systems would be helpful. I could gather those from jabber.org (300k
registered users, typically about 10-15k online at any one time) and
from smaller enterprise deployments as well.

Peter

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

---

From: "Willekens, Marc" <[email-masked]>
Date: Thu, 4 Oct 2007 20:41:09 +0200

Hi Peter,

Yes, your results are dazzling. The indication of 1,5% bandwidth in comparison with SIP/SIMPLE is certainly unexpected and requires further investigation. The figure I once had was ca. 80%. So, it really depends on the used model for a more realistic comparison.

1. First point is that you have based yourself on a SIP/SIMPLE analysis document which had an error in the calculation resulting in a higher bandwidth.
Please look at the updated document:
http://www.nostrum.com/~rjsparks/draft-ietf-simple-interdomain-scaling-analysis-02.txt

2. In §4.3 "Steady state messages", you have used to formula (C02*(C01-2)). In the SIP/SIMPLE document, the formula C02*C01-2 is used. So, this resuls in many less XMPP related messages.

3. For the §5.3 "Very large network peering", you considered a presence state change of 3/hour while in the SIP/SIMPLE 6 changes/hour are considered. So, this is again a smaller amount of XMPP messages.

4. For SIP/SIMPLE a presence document of 3000 Bytes is used, while for XMPP you use a 200 byte XML presence document.

New calcuations:
---------------
With the correction of 1. and 2. the results for the total amount of msgs and bytes are:
						(your values        ) 
basic:	   139	   26667	(   116	   22222)
widely:	   694	  133333	(   583	  113889)
very-large:	173611	33333333	(145833	27777777)
intra:	  1042	  200000	(   875	  170833)

compared with SIMPLE, this gives 47,58% for the #msgs and 4,71% for the #bytes/sec as an average for all these 4 models. 

When the size of the presence document is considered in the same order for SIMPLE and XMPP, a more honest comparison between the two protocols can be made.

In my model, I used 150 bytes for the subscription request, 150 bytes for the notification and 3000 bytes for the presence document itself.

This gives also 47,58% for the #msgs and 71,31% for the #bytes/sec as an average.
The same model with SIMPLE partial notification results in:
#msgs: 47,58% and #bytes: 197.53!
This is explained by the fact that the XMPP presence document is 3000 bytes and for the SIMPLE: 3000 bytes for the full notify abd 200 bytes for the partial notification.

By changing the SIMPLE model by considering a compression factor of 3/5 for the subscrite, 200OK and notify message and a presence document of 240 bytes and by keeping your XMPP model of (100 and 200 bytes) and by making use of the SIMPLE partial notification the result is:

47,58% for the #msgs and 27,8 #bytes/sec.

With this last model and considering a higher frequency of presence state change of 5sec instead of 20 min, the result is:

49,98% for the #msgs and 31,23 #bytes/sec.

Conclusion:
The amount of XMPP msgs is ca. 48%. This is normal because no ack. messages (200 OK) are used in XMPP.
The amount of XMPP bytes is ca. 30% of SIMPLE. This is the case when the presence document is nearly the same order as the SIP header. For longer presence documents, the influence of the SIP header becomes smaller and as such the bandwidth can go to ca. 80%.

br,
Marc.

-----Original Message-----
From: ext Peter Saint-Andre [mailto:[email-masked]] 
Sent: dinsdag 2 oktober 2007 19:25
To: [email-masked]
Subject: [Simple] [Fwd: I-DAction:draft-saintandre-xmpp-presence-analysis-01.txt]

FYI

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 04 Oct 2007 15:27:39 -0600

Willekens, Marc wrote:
> Hi Peter,
> 
> Yes, your results are dazzling. 

They were not meant to be dazzling. They were meant to be accurate.

> The indication of 1,5% bandwidth in
> comparison with SIP/SIMPLE is certainly unexpected and requires
> further investigation. The figure I once had was ca. 80%. So, it
> really depends on the used model for a more realistic comparison.

Indeed it does. And, as I said, some real-world numbers would help.

> 1. First point is that you have based yourself on a SIP/SIMPLE
> analysis document which had an error in the calculation resulting in
> a higher bandwidth. Please look at the updated document: 

Oh, thanks, I didn't know about that interim version. I'll correct my
analysis per that draft and work to submit an updated XMPP analysis
today or tomorrow.

> 2. In §4.3 "Steady state messages", you have used to formula
> (C02*(C01-2)). In the SIP/SIMPLE document, the formula C02*C01-2 is
> used. So, this resuls in many less XMPP related messages.

You are right, that was a misunderstanding. Corrected in my working copy.

> 3. For the §5.3 "Very large network peering", you considered a
> presence state change of 3/hour while in the SIP/SIMPLE 6
> changes/hour are considered. So, this is again a smaller amount of
> XMPP messages.

Oops, a copy-and-paste error. Corrected in my working copy.

> 4. For SIP/SIMPLE a presence document of 3000 Bytes is used, 

As far as I can see, that number is still in the SIP analysis at
http://www.nostrum.com/~rjsparks/draft-ietf-simple-interdomain-scaling-analysis-02.txt

Do the authors of that specification agree that 3000 bytes is incorrect
and, if so, what do they think is correct? If possible I would prefer to
track the published version of the SIP analysis (or an in-progress
update thereto).

> while
> for XMPP you use a 200 byte XML presence document.

Correct. In fact that's a bit large, but I didn't want to underestimate.
In fact we don't have presence "documents" but that's close enough.

> --------------- With the correction of 1. and 2. the
> results for the total amount of msgs and bytes are: (your values
> ) 

> basic:	139	   26667	(116	   22222) 

Agreed.

> widely:	694	  133333	(583	  113889) 

I get 694 and 136,111.

> very-large:	173611	33333333	(145833	27777777) 

I get 340,278 and 66,666,667.

> intra: 	1042	  200000	(875	  170833)

I get 1042 and 204,167.

> compared with SIMPLE, this gives 47,58% for the #msgs and 4,71% for
> the #bytes/sec as an average for all these 4 models.

I think 47.58% is off. How did you calculate that?

Using my figures from above and the figures from
http://www.nostrum.com/~rjsparks/draft-ietf-simple-interdomain-scaling-analysis-02.txt
I get the following results using the per-second figures.

BASIC

31% of the messages (139 vs. 444)
3.8% of the bytes (26,667 vs. 707,500)

WIDELY DISTRIBUTED INTER-DOMAIN PRESENCE

31% of the messages (694 vs. 2,222)
3.8% of the bytes (136,111 vs. 3,537,500)

VERY LARGE NETWORK PEERING

38% of the messages (340,278 vs. 888,889)
4.4% of the bytes (66,666,667 vs. 1,529,375,333)

INTRA-DOMAIN PEERING

31% of the messages (1042 vs. 3,333)
3.8% of the bytes (204,167 vs. 5,306,250)

> When the size of the presence document is considered in the same
> order for SIMPLE and XMPP, 

It's not clear to me what you mean by "in the same order".

> a more honest comparison between the two
> protocols can be made.

I see no evidence to indicate that the people performing these analyses
are doing so in anything less than an honest manner.

> In my model, I used 150 bytes for the subscription request, 150 bytes
> for the notification and 3000 bytes for the presence document itself.

Is your model documented somewhere?

Are those numbers for SIMPLE or XMPP?

> This gives also 47,58% for the #msgs and 71,31% for the #bytes/sec as
> an average. The same model with SIMPLE partial notification results
> in: #msgs: 47,58% and #bytes: 197.53! 

I left optimizations out of my calculations in order to compare apples
to apples, and because I am not familiar enough with the optimizations
in SIMPLE to say whether they are approved, implemented, and deployed.
However I may add the optimized numbers to a future version of the XMPP
analysis.

> This is explained by the fact
> that the XMPP presence document is 3000 bytes 

Where do you get 3000 bytes for an XMPP presence packet? That is
completely inconsistent with RFC 3920, RFC 3921, and over 8 years of
deployment experience.

> and for the SIMPLE:
> 3000 bytes for the full notify abd 200 bytes for the partial
> notification.
> 
> By changing the SIMPLE model by considering a compression factor of
> 3/5 for the subscrite, 200OK and notify message and a presence
> document of 240 bytes and by keeping your XMPP model of (100 and 200
> bytes) and by making use of the SIMPLE partial notification the
> result is:
> 
> With this last model and considering a higher frequency of presence
> state change of 5sec instead of 20 min, the result is:
> 

As mentioned, I may look at adding optimized calculations to a future
version of the XMPP analysis.

Naturally, to compare apples to apples we'd need to include stream
compression in XMPP, which can be accomplished either with native TLS
compression or application-layer compression (documented in XEP-0138).
Given that XMPP sessions are long-lived XML streams that include much
redundant information (lots of instances of <presence> and </presence>
and so on) and a single XML parser instance, deployment experience
indicates that significant bandwidth savings can be achieved (on the
order of 90% or perhaps even more for presence, which does not include
custom or user-specific information). But I have not performed such an
analysis to date, mostly for lack of time.

> Conclusion: The amount of XMPP msgs is ca. 48%. This is normal
> because no ack. messages (200 OK) are used in XMPP. The amount of
> XMPP bytes is ca. 30% of SIMPLE. This is the case when the presence
> document is nearly the same order as the SIP header. For longer
> presence documents, the influence of the SIP header becomes smaller
> and as such the bandwidth can go to ca. 80%.

Again, it's not clear to me exactly what your assumptions are. Perhaps
you could contribute to the next version of
draft-ietf-simple-interdomain-scaling-analysis so that your assumptions
and analysis can be fully documented.

Thanks for the feedback!

Peter

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

---

From: Dave Cridland <[email-masked]>
Date: Thu, 04 Oct 2007 23:16:07 +0100

On Thu Oct  4 19:41:09 2007, Willekens, Marc wrote:
> 4. For SIP/SIMPLE a presence document of 3000 Bytes is used, while  
Brian Rosen suggests that the 3k SIP presence document is way too big  
- or at least, that's how I read his message. For XMPP, Peter  
suggested that he'd pulled that figure based on some study of the  
deployment at jabber.org. I've personally never seen a presence  
stanza anything like 3k - maybe I'm looking in the wrong place.

I can't claim to be a disinterested observer, but that figure for  
XMPP looks right to me. Peter has much better resources for gaining  
solid figures for XMPP than I do, however. A better idea would be  
gaining similarly solid figures for SIMPLE.

I'd also point out that the standards trend in XMPP is to reduce the  
size of the presence stanzas, keeping presence stanzas purely for  
presence, and moving some of the more weird and wonderful data (like  
what track you're listening to) to other technologies such as PEP,  
which is a publish/subscribe model. (See XEP-0163, and XEP-0118 for  
the specific case of "User Tune").

This suggests that the comparison is unfair only on the SIP/SIMPLE  
side - the presence stanza is unlikely to get much bigger in XMPP.  
(Typically, they're larger than the example Peter gives, since most  
clients use the entity capabilities facility to include capability  
caching in the presence, see XEP-0115). I would, however, entirely  
believe that SIMPLE presence documents are generally going to be much  
smaller than 3k, which seems very big to me.

Of course, if PEP becomes widely deployed for many forms of  
quasi-presence data, we'll see a rise in packets in XMPP.

> 						(your values        ) basic:	   139	   26667	(   116	   22222)

This seems about right.

> order for SIMPLE and XMPP, a more honest comparison between the two  
> protocols can be made.
> 
> In my model, I used 150 bytes for the subscription request, 150  
> bytes for the notification and 3000 bytes for the presence document  
> itself.
> 
> 
This seems wrong - you're claiming that XMPP has a presence stanza  
considerably larger than it actually does.

> This is explained by the fact that the XMPP presence document is  
> 3000 bytes and for the SIMPLE: 3000 bytes for the full notify abd  
> 200 bytes for the partial notification.
> 
> 
You're correct that XMPP has no partial notification, but given PEP  
that's unlikely to be needed - PEP essentially gives partial  
notification for free. Even in the current deployments, though,  
presence stanzas don't - in my experience - come anywhere close to  
3k, even when using some of the more verbose clients out there.

> document of 240 bytes and by keeping your XMPP model of (100 and  
> 200 bytes) and by making use of the SIMPLE partial notification the  
> result is:
> 
Calculating the effects of compression as a fixed factor works for  
SIMPLE, but not for XMPP. This is because XMPP uses TCP, so given  
multiple presence stanzas for the same user to a foreign domain, they  
will all travel - typically one after the other - over a single  
stream. (They're generated by the server, so it seems unlikely you'd  
get anything but that behaviour. As a brief aside, I suspect Peter's  
packet counts are out here as a result - they're correct as a stanza  
count, but typical servers will be sending out multiple stanzas in a  
single TCP packet).

Given any form of stream compression - TLS or XEP-0138 - these  
compress exceedingly well, given their similarity. I wouldn't like to  
guess, but I certainly found in some limited, simple, tests that very  
good compression ratios were achieved.

Modelling this as a fixed compression ratio, equally applicable to a  
single presence stanza or typical presence stanza sequences, simply  
doesn't apply to XMPP - the more presence stanzas you need to send  
between domains on behalf of a single user, the better these will  
compress.

On some simple testing using gzip (both TLS and XEP-0138 use the  
deflate algorithm underneath, as does gzip), 500 such presence  
documents (simple ones of 162 octets or so) compress down from 81890  
to 1738 bytes, a compression ratio of 2%. 20, a more realistic  
number, compress from 3250 to 224 bytes, or 7%.

Both those tests are, of course, performed in isolation - typically  
the algorithm will be capable of compressing better in a real-world  
setting, and other factors will come into play which would probably  
reduce the effectiveness, too. Real world testing, as ever, is needed.

In summary, once you allow both protocols to use compression, I'd  
personally throw those figures away. My gut feeling - and I'd love to  
know whether I'm right - is that they're out by an order of magnitude.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Oct 2007 22:12:00 -0400

Regarding the size of presence documents:

I believe the 3000 byte presence document assumes that rich presence is 
used. If only basic presence was assumed then the number would be much 
smaller.

I gather that XMPP numbers are predicated on something comparable to 
simple presence.  Its been a long time since I looked, but as I recall 
the xmpp presence message was advertised as being able to carry 
arbitrary extensions including the sip rich presence.

So it seems to me that the choice of whether to model using the large 
size or the small size should be based on an assumption fo how rich of 
presence the users desire, not on which protocol is being used.

	Paul

Peter Saint-Andre wrote:
> ------------------------------------------------------------------------
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 4 Oct 2007 21:43:00 -0700

> Thanks for the feedback. Let's get this right!

Keep in mind that people that are concerned about bandwidth in SIP  
use SigComp so you probably want to include that.

---

From: <[email-masked]>
Date: Fri, 5 Oct 2007 09:35:17 +0300

Hi,

Cullen Jennings [mailto:[email-masked]] wrote:
>Keep in mind that people that are concerned about bandwidth in 
>SIP use SigComp so you probably want to include that. 
>

In practice SigComp is mainly intended to be used between SIP UA and an
outbound proxy to save bytes on the access network. I suppose in
principle you could use it even between proxies/domains, but have not
heard anyone consider that. But end-to-end mechanisms like subnot-etags
and partial notifications will help all the way.

Markus

---

From: Avshalom Houri <[email-masked]>
Date: Fri, 5 Oct 2007 08:50:25 +0200

I agree. Did not read the whole thread yet but this is the same point that 
I wanted to raise.
See 2.10 and its conclusion in 
http://www.nostrum.com/~rjsparks/draft-ietf-simple-interdomain-scaling-analysis-02.txt
The section compares one use case of SIMPLE and an extremely bandwidth 
saving protocol and it gets a saving of about a half.
I think that the two protocols should be compared based on the same 
presence document size.

--Avshalom

Paul Kyzivat <[email-masked]> 
05/10/2007 04:12

To
Peter Saint-Andre <[email-masked]>
cc
[email-masked]
Subject
Re: [Simple]    [Fwd: 
I-DAction:draft-saintandre-xmpp-presence-analysis-01.txt]

                 Paul

---

From: Avshalom Houri <[email-masked]>
Date: Fri, 5 Oct 2007 09:07:05 +0200

I recall that TLS do compress bytes (dependent on the encryption used).
Assuming that servers will be using TLS between them, do we have numbers 
on the compression ratio that can be achieved per type of encryption?

--Avshalom

<[email-masked]> 
05/10/2007 08:35

To
<[email-masked]>, <[email-masked]>
cc
[email-masked]
Subject
RE: [Simple] 
[Fwd:I-DAction:draft-saintandre-xmpp-presence-analysis-01.txt]

Hi,

Markus

---

From: "Peter Saint-Andre" <[email-masked]>
Date: Fri, 5 Oct 2007 08:40:40 -0600 (MDT)

> I think that the two protocols should be compared based on the same

I think that the two protocols (or any others) should be compared based on
the same use cases. Whether achieving the same functionality (say a given
kind of rich presence such as user activity) requires the same number of
bytes is a matter of protocol design. I seems rather arbitrary to
stipulate that Protocol X and Protocol Y require the same number of bytes
to achieve Use Case A even if that is not the case in the protocol
specifications or deployed reality.

I agree that there are many possible use cases for presence, including
extended presence (e.g., device capabilities) and rich presence (e.g.,
user mood and user activity). We need to clearly define those use cases
and scope out how they are achieved in SIMPLE and in XMPP. And then we
need to investigate how each protocol optimizes performance; examples in
SIMPLE include partial notifications and etags, examples in XMPP include
stream compression and offloading information that is not directly related
to network availability onto a more generic publish-subscribe mechanism
that we call personal eventing.

Furthermore, we need to ask ourselves what we are trying to achieve here.
As far as I understand it, the original focus of
draft-ietf-simple-interdomain-scaling-analysis was to analyze the state of
interdomain presence scaling in SIP/SIMPLE, and to recommend solutions to
perceived problems. When I read that analysis I got interested in seeing
how XMPP would compare using the same analytic techniques. There are many
reasons to choose one technology over an another (or to use both!), and it
was not my intent to get into a shouting match over presence technologies.

I still think it might be helpful to formulate common techniques for
analyzing presence technologies. I don't know what the proper venue is for
such work. Perhaps it makes more sense for the SIMPLE WG to focus on its
optimizations (partial notifies, etags, etc.) and for the XMPP developer
community to focus on its optimizations (compression, personal eventing,
etc.) without directly comparing the two technologies as we have been
doing, since these efforts seem to have generated more heat than light and
there is an unfortunate tendency for people to think in terms of "sides"
and "protocol wars". That makes good copy, but one would hope that we
could leave such sensationalistic thinking to the journalists and (as
technologists) pursue a more scientific, objective approach.

In any case, I will be offline for the next 10 days and will be unable to
look at this issue for at least two weeks. At that time I may work to add
some of the rich presence use cases to the XMPP analysis. I may also
remove the references to the SIP analysis, since they seem to be
contentious and counter-productive. And, as mentioned, once
draft-ietf-simple-interdomain-scaling-analysis is updated I will be happy
to update the XMPP analysis to track changes to the analytic model
contained in that document.

Peter

---

From: "Willekens, Marc" <[email-masked]>
Date: Fri, 5 Oct 2007 17:26:34 +0200

Hi Peter,
I agree with your point of view. Each protocol has its own advantages
and disadvantages. It's always good to be able to make a selection out
of different protocols in function of the need for certain type of
application or use cases. And IETF should try to provide these basic
building blocks.

Just comparing the bandwidth issue between XMPP and SIMPLE is maybe not
that important and certainly not for companies earning money in selling
bandwidth. The main concern is not the bandwidth by itself but the
control of this bandwidth. In case of overload or misuse, mechanism
should be there to tackle it.
And when we look at another very popular IM and presence system such as
SecondLife, then the bandwidth usage of XMPP and SIMPLE becomes totally
neglectible. Does somebody knows what kind of protocol Lindenlabs is
using for the IM/Presence/Voice in Secondlife?

The big, basic difference between XMPP and SIMPLE is the usecase:
1. XMPP was provided for a long-term connection to exchange many short
XML type documents. The scope of XMPP is not directly related to a voice
service, but more to application use between machines and persons.
2. SIMPLE was provided to subscribe to relatively short-lived events,
such as a conference call. As such, SIP presence subscriptions are not
persistent and must be renewed periodically (e.g. once an hour). SIMPLE
is part of the RAI and it's scope is limited to real-time interperson
communication.
 
When the basic and extended presence is considered, both XMPP and SIMPLE
have their own approaches to address these issues:
1.SIMPLE
Threat both basic and extended presence as conceptually the same but use
filtering and authorization rules so that presence engines can control
which entities are allowed to publish and receive particular kinds of
extended presence data. This approach keeps basic presence and extended
presence together but tends to introduce quite a bit of complexity into
presence engine design and implementation.
 
2. XMPP
Threat basic presence and extended presence as conceptualy similar but
distinct by handling extended presence through dedicated pub/sub engines
rather than core presence engines.This approach separates extended
presence from basic presence and enables greater flexiblity and
granularity in managing extended presence services. 
 
Right now, it's too early to say which is the right approach to handling
extended presence. However, experience from certain persons with other
forms of rapidly changing information such as RSS feeds indicates that
the pub/sub approach used in XMPP has inherent advantages with regard to
scalability, filtering and control. This is a statement I once heard,
but I don't have evidence to justify this. Maybe, it's worth to
investigate this further.

br,
Marc.  

-----Original Message-----
From: ext Peter Saint-Andre [mailto:[email-masked]] 
Sent: vrijdag 5 oktober 2007 16:41
To: Avshalom Houri
Cc: [email-masked]
Subject: Re: [Simple] [Fwd:

> See 2.10 and its conclusion in
http://www.nostrum.com/~rjsparks/draft-ietf-simple-interdomain-scaling-a
nalysis-02.txt
> I think that the two protocols should be compared based on the same

I think that the two protocols (or any others) should be compared based
on
the same use cases. Whether achieving the same functionality (say a
given
kind of rich presence such as user activity) requires the same number of
bytes is a matter of protocol design. I seems rather arbitrary to
stipulate that Protocol X and Protocol Y require the same number of
bytes
to achieve Use Case A even if that is not the case in the protocol
specifications or deployed reality.

stream compression and offloading information that is not directly
related

Furthermore, we need to ask ourselves what we are trying to achieve
here.
As far as I understand it, the original focus of
draft-ietf-simple-interdomain-scaling-analysis was to analyze the state
of
interdomain presence scaling in SIP/SIMPLE, and to recommend solutions
to
perceived problems. When I read that analysis I got interested in seeing
how XMPP would compare using the same analytic techniques. There are
many
reasons to choose one technology over an another (or to use both!), and
it
was not my intent to get into a shouting match over presence
technologies.

analyzing presence technologies. I don't know what the proper venue is
for
doing, since these efforts seem to have generated more heat than light
and

In any case, I will be offline for the next 10 days and will be unable
to
look at this issue for at least two weeks. At that time I may work to
add
some of the rich presence use cases to the XMPP analysis. I may also
remove the references to the SIP analysis, since they seem to be
contentious and counter-productive. And, as mentioned, once
draft-ietf-simple-interdomain-scaling-analysis is updated I will be
happy
to update the XMPP analysis to track changes to the analytic model
contained in that document.

Peter

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 05 Oct 2007 20:11:16 +0300

Hi Peter,

I agree each protocol has its own advantages and disadvantages, 
and I also I fully agree that the two protocols (or any others) should
be compared based on the same use cases.

However we should not forget when we perform the analysis that the two
protocols have two different way to handle the basic and extended
presence , and March has explained extremely well in his previous mail

> granularity in managing extended presence services. 

I do believe we should take this in consideration and start analyzing as
you have well done in the draft-saintandre-xmpp-simple-10 the "least
common denominator" of network availability only.

My proposal is to take in consideration the amount of bytes you obtain
translating (as done in the xmpp-simple-10) the basic XMPP in the basic
Notify.

So while I don't have any doubts xmpp is somewhat more efficient, I
think the difference will be more fear and nowhere near the difference
claimed in the draft.

Having done that we should start to think how to proceed with the
extended presence, and finally analyzing also the different optimization
in the two protocols. 

/sal

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 6 Oct 2007 15:11:44 -0700

On Oct 4, 2007, at 11:35 PM, <[email-masked]>  
<[email-masked]> wrote:

> heard anyone consider that.

Completely agree but I think that is just because bandwidth has not  
been an issue there.