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='juliet@example.com/balcony'
       to='romeo@example.net/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:user@watcherhost.example.com SIP/2.0
      Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk
      From: <sip:resource@example.com>;tag=ffd2
      To: <sip:user@example.com>;tag=xfg9
      Call-ID: 2010@watcherhost.example.com
      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:someone@example.com">
     <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:stpeter@stpeter.im]
> Sent: Tuesday, October 02, 2007 1:25 PM
> To: simple@ietf.org
> Subject: [Simple] [Fwd: I-DAction:draft-saintandre-xmpp-presence-analysis-
> 01.txt]
> 
> 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
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple