[Standards] Council on Stanza Repeaters without Multicast

Philipp Hancke fippo at goodadvice.pages.de
Thu Apr 3 09:35:55 UTC 2008

Dave Cridland wrote:
>> I notice what you mean.. repeaters have double 'from'.. the sending
>> server and the originating sender. In a simple no-trust situation
>> these SHOULD be on the same host or domain, then my server is merely
>> sending stanzas in my name in a more efficient way. That's something
>> to add to "10. Security Considerations".
> Yes, I concur that this - although weird - doesn't introduce any 
> fundamental security issues if done right. However, it does make it 
> easier to break thing at the implementation stage.

I think I would prefer to use repeaters directly instead of wrapping
stanzas. That can even reduce overhead to the size of the hash:
<presence from='romeo at montague/garden'
   <status>I am here</status>
It makes error handling a little more tricky, though.

> Right, but *NONE OF THESE* figures take into account two things:
> A) Compression
> It's crucial on two counts:
> 1) It's much simpler to implement, and
 > 2) Given that we are (or should be) encrypting every S2S
 >    connection, then TLS is giving us compression anyway, and
 >    moreover, it's cheaper to compress than not to compress.

Sure. But:
1) Compression does not reduce the number of stanzas or the
    number of bytes your parser has to parse.
2) you can't apply "karma" to compressed traffic. If you do, you
    can also just stop rate-limiting. Example:
    you accept 5kb/s compressed traffic on a c2s link. That is
    forwarded to a single s2s link, which does not support
    compression. The stanzas result in s2s traffic of 50kb/s,
    which is going to congest the s2s connection (jabberd14
    karma limits).

> We've been down the road before where on some admittedly fairly simple 
> figures I did a while back - and repeated for Peter's scalability draft 
> in the SIMPLE WG, I think - the existing presence "splurges" compress 
> really well, often better than the "optimized" alternatives.

The size of compressed non-optimized traffic is smaller than the
size of compressed "optimized" traffic?

> B) RTT delays
> The introduction of Stanza Repeaters gives us RTT delays whenever a list 
> needs changing. That just strikes me as worrying - I don't think anyone 
> has clear figures on how much delay would be introduced, but I'm sure 
> you'll agree that additional latency does not a performance improvement 
> make.

That depends on how often those lists change.

> It may be possible to alter the protocol to remove these.

calculating repeater addresses in advance?

>> He resumes:
>> | Regardless of protocol details, the concept of remote fan-out using
>> | lists stored on the remote side is superior to the "current" way of
>> | doing things.
> That's an opinion, not a fact. The facts are that Stanza Repeaters *do* 
> introduce at least some round-trips, and have not been considered WRT 
> post-compression figures, which the scalability drafts specifically 
> don't touch because it would put XMPP in such a horrific advantage to 
> SIMPLE, and is exceedingly difficult to put into a simple formula.

Repeaters can reduce the traffic to 10% the size of pre-compressed
traffic. Even less when compared to rfc3920-style instead of 
3920bis-style. Without the disadvantages mentioned above.

The main advantage of repeaters is not the reduced traffic, it is
the reduced number of stanzas.

>> <Kev> right, we don't have, still, afaik a decent model for testing
>>       the effect of such things on 'real' usage
>> I hope stpeter's draft isn't the worst of choices.
> Not the worst of choices, but bear in mind that the draft in question 
> was a comparison to a draft discussing SIP/SIMPLE scaling - it doesn't 
> match XMPP usage, but a rather sterile guess at probable activities of 
> SIMPLE users. So Kevin's right here - we don't have a decent model, and 
> the best one we have is basically forced on us from another protocol.

That applies to the scenarios, not the model (the formulas) itself?

>> With the security set-up in place, you can only mess up your local
>> data, as always. Repeaters, if properly defined, are just an 
>> optimization.
>> Why shouldn't the packets inside be treated to the same scrutiny as
>> any packet?
> Because they pass through a different code-path, there is a stronger 
> likelyhood of bugs.

That's a shortcoming of the wrapping-approach, not of repeaters.

More information about the Standards mailing list