Re: Proposed XMPP Extension: Stanza Repeaters

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://w
ww.xmpp.org/extensions/xep-0018.html
> or:
> 
> http://w
ww.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='poweruserexample.net/foo'
 
to='repeater.example.com/somehashsomehashsomehashsomehashsom
ehash'
  type='probe'/>
That (125 bytes) is already less bytes than two probes to
the
remote domain, which amount to ~160 bytes:
<presence from='poweruserexample.net/foo'
to='user1example.com'
  type='probe'/>
<presence from='poweruserexample.net/foo'
to='user2example.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