On Wed Apr 2 23:22:12 2008, [EMAIL PROTECTED] wrote:
I was pointed to your council meeting log at
http://logs.jabber.org/[EMAIL PROTECTED]/2008-04-02.html
Given that PSYC's webpages suggest that "Only politics can stop that
now", I think we may be off to a non-useful conversation, here, but
anyway.
Some thoughts and numbers about
http://www.xmpp.org/extensions/inbox/repeaters.html
you discussed between 14:40 and 14:55.
<Kev> this is an odd spec - it loses us the 'no spoofing' which we
currently enjoy
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.
<Dave> I'm not wholly convinced that, in the current design, it will
actually result in "better" network usage.
<Dave> The single thing that worries me most on this is simply that
nobody seems to have done any figures on whether this
genuinely saves
bandwidth.
I know Fippo's postings aren't the easiest read. He expects
everyone to
be as deep in it as he is himself. He has used stpeter's model from
http://www.xmpp.org/internet-drafts/draft-saintandre-xmpp-presence-analysis-03.html
found a bug in the formulas, then with the corrected formula
figured out
numbers for scenario 5.1 as follows:
580000000 for the "standard" behaviour of xmpp (also dubbed "rfc")
251200000 for repeaters XEP
197200000 for smart presence XEP from 2004
For completeness, smart presence is here:
http://www.xmpp.org/extensions/inbox/smartpresence.html
It basically does the same as repeaters, but focused on presence
only.
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.
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.
Smart Presence was one proposal that beat pure compression, as I
recall, but it has security implications which I'm not going to
accept.
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.
It may be possible to alter the protocol to remove these.
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.
This isn't even taking into account what a huge gain repeaters
represent when applied to MUCs. large pubsubs also start having
a chance to actually scale.
But you can do both MUC and PubSub way better if you design something
specific to them, and I think that's possible to do.
All of this gets even better when you apply real multicast to it,
but you don't need to worry about that now. You are already
improving a lot by being more strategic in the way you unicast.
That is what the repeaters XEP and similar earlier protoXEPs
propose.
Unfortunately, your notions of junctions and multicast simply don't
fit the security model of XMPP. They do, however, work perfectly well
if considered as a highly distributed XMPP cluster, but that's
another story.
<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.
Not at all. My sendmail is busy until next day to distribute to a
few
thousand recipients. Ok, sendmail is stupid, but I wouldn't want it
to
try to connect a thousand hosts at the same time. IRC can handle
that
much better, so does PSYC. How? It just forwards to some thirty
hosts
which themselves forward to some thirty hosts. Stuff arrives in near
real-time, even with thousands of recipients. That's why multicast
is
the only way to go. And persisting recipient lists is fundamental to
have a ghost of a chance of being scalable. I've done this stuff for
a decade now, you can trust I know what I'm talking about.
Unfortunately, email did this for several years - probably before
your time - and look what happened.
And please don't say that IRC has done this for several decades,
unless you want me to have you explain how I can run up my own IRC
server and talk to anyone else on IRC. Consider, for a moment, why
I'm sending you this using SMTP, and not X.400 (my mailserver *DOES*
speak both).
So no, I'm not going to trust you. In fact, it's my job here not to
trust you, so don't take that personally.
<Dave> I'm pretty sure it'd be easy to write a repeater that did
allow
spoofing, and moreover, bypassing of privacy lists, etc.
But I don't think it's a fundamental property of repeaters.
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.
<stpeter> Dave: it saves bandwidth compared to XEP-0033
<stpeter> (which may not be saying much)
<Dave> stpeter, No, I mean, does it save bandwidth compared no not
having it.
No comment.
I hope my comments above have explained that in more detail.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
