[Standards] Proposed XMPP Extension: Stanza Repeaters

Tobias Markmann tmarkmann at googlemail.com
Mon Mar 24 14:11:36 UTC 2008


On Mon, Mar 24, 2008 at 1:45 PM, Philipp Hancke
<fippo at goodadvice.pages.de> wrote:
> Peter Saint-Andre schrieb:
>
> > Philipp Hancke wrote:
>  >> Peter Saint-Andre schrieb:
>  >>>> Interesting optimization - as far as the traffic savings are concerned.
>  >>>> Yet it breaks invisible (at least): it makes the sender appear online to
>  >>>>  the other side indefinitely.
>  >>> Invisible is broken anyway.
>  >> yai.
>  >>
>  >>> And which version of invisible are you talking about?
>  >
>  > I meant:
>  >
>  > http://www.xmpp.org/extensions/xep-0018.html
>  > or:
>  >
>  > http://www.xmpp.org/extensions/xep-0126.html
>
>  I think my scenario applies to both, even though I don't
>  see an explicit "logging in as globally invisible" in
>  the former.
>
>
>  > Or something else?
>  >
>  >> The scenario where the remote contact is online when you send
>  >> the probe, but does not respond (blocked outbound presence).
>  >> Then he receives your initial presence, but never receives updates
>  >> (S2*C4) or the terminating presence stanza.
>  >
>  > Life is hard. Don't go invisible. :P
>
>  Especially don't go invisible and send probes ;-)
>
>  [snip]
>
> >> Touché. Why don't you mention the usage of this optimization in
>  >> http://www.xmpp.org/internet-drafts/draft-saintandre-xmpp-presence-analysis-03.html
>  >>
>  >> which refers to 3920+3921?
>  >
>  > Because that spec is not done yet?
>
>  Then why are you using the optimization? I think that other protocol has
>   more traffic than even non-optimized XMPP. And you have a very good
>  showcase for the optimizations in -bis when comparing both versions ,-)
>
>
>  >> So we have three alternatives to compare:
>  >> 1) rfc-style (and the looser is...)
>  >> 2) bis-style
>  >> 3) repeaters
>  >>
>  >> My script indicates that repeaters 'win' (measuring B4 or B6, neglecting
>  >> creation overhead) against bis-optimizations in scenarios 1, 2, 4 and 5
>  >> but lose in scenario 3 (with B6 25166 instead of 22917).
>  >> They 'win' always when measuring B5.
>  >> 2000 bytes in B2 seem to be the minimum amount that could be 'wasted'
>  >> for repeater creation (in scenario 1), which afaics amounts to 550 bytes
>  >> for that scenario (plus disco + deletion).
>  >
>  > Thanks for looking into this. Despite the fact that we did not think
>  > about repeaters primarily for the sake of presence, it seems that it
>  > might be helpful here, too.
>
>  Helpful? ;-)
>  B6 for scenario 5:
>  rfc:       199444444 bytes/second
>  bis:        45000000 bytes/second
>  smart/rep:   4544444 bytes/second
>  As you can see, smart/repeaters is uncompressed as good as bis-opts with
>  compression. I wonder how good the compression ratio will be with the
>  repeater data... I'd rather expect compressed traffic that is 20% the
>  size of the traffic before compression.
>
>  I don't think we need to discuss the usefulness of repeaters in MUC and
>  pubsub. The gain is obvious there, because the stanza rate is usually
>  much higher than 3/hour ;-)
>
>  The main problem with the bis-optimizations is that they only work well
>  if C4/C3 is small. But you never know C4 in advance. So when do you use
>  repeaters, when should you use the -bis optimizations?
>
>  Afaics, the 'biggest' problem of the repeater approach is the large
>  overhead (180 bytes) if the stanza itself is small.
>
>  I think it is possible to lower that overhead to the 40 bytes of the
>  hash hexcode:
>  <presence from='poweruser at example.net/foo'
>   to='repeater.example.com/somehashsomehashsomehashsomehashsomehash'
>   type='probe'/>
>  That (125 bytes) is already less bytes than two probes to the
>  remote domain, which amount to ~160 bytes:
>  <presence from='poweruser at example.net/foo' to='user1 at example.com'
>   type='probe'/>
>  <presence from='poweruser at example.net/foo' to='user2 at example.com'
>   type='probe'/>
>
>  If we can eliminate repeater creation overhead the trade-off point
>  could be 2:
>  Create and store once, 'never' forget until the last
>  local contact of the repeater creator is gone (this is almost like
>  storing a roster for the remote user). The hash acts as a checksum
>  to make sure there is no desync.
>
>  Repeaters are already a giant leap in the right direction, but I think
>  that there are optimizations which would make the fan-out idea usable
>  even for one or two recipients on each server.
>
>  Philipp
>
>

Nice. I haven't seen the argument yet but maybe I've just overlooked
it. Reducing the number of presence and message stanzas don't just
reduce traffic but maybe a more important fact is that the servers
need to parse less XML and need to route less stanzas internally. It's
a big improvement since a big part of the overall processing time of a
server is spend on XML parsing.

Tobias


More information about the Standards mailing list