[Standards] Proposed XMPP Extension: Stanza Repeaters

Philipp Hancke fippo at goodadvice.pages.de
Mon Mar 24 12:45:16 UTC 2008

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 ;-)

>> 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'
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'
<presence from='poweruser at example.net/foo' to='user2 at example.com'

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.


More information about the Standards mailing list