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='[EMAIL PROTECTED]/garden'
to='capulet/35bb0982414b54184d14a961cf749de92d1cd952'
<status>I am here</status>
</presence>
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.
