[Standards] Council on Stanza Repeaters without Multicast

Carlo v. Loesch CvL at mail.symlynX.com
Thu Apr 3 12:00:33 UTC 2008


Changed the order of discussion: Important stuff first.

Dave Cridland typeth:
| The introduction of Stanza Repeaters gives us RTT delays whenever a  
| list needs changing. That just strikes me as worrying -
| It may be possible to alter the protocol to remove these.

Yes that's a bad idea. It must be possible to send data on the modified
repeater right away without waiting for feedback. TCP failures are a
separate problem. Addressing them by inconsistent application-level
redundancies here and there is not the way to go. I agree on removing
this.

| 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.

That is exactly what the "smart" protoXEP series was about.
One specific strategy for presence and one for chat were in place
and we were about to write a "smart" pubsub and a multicast xep
on top of all of them which would make them all capable of tree
distribution structures if the trust requirements are given.
 
So then you have a fundamental decision to take here. Do you
want a swiss army knife like Repeaters or precision tools like
the "smart" series? I stopped being religious on that, I just
want XMPP to move forward as I can't avoid using it myself in
everyday situations.

| Right, but *NONE OF THESE* figures take into account two things:
| 
| A) Compression

We had that discussion before, too.

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

That is not an opinion, but the summary gained from the mathematical
model given. No matter which scenario was applied to the model, that
was the result.

| *do* introduce at least some round-trips, and have not been  

Yes, just change Repeaters so that they won't wait for the change
to be processed before sending content.

| Smart Presence was one proposal that beat pure compression, as I  
| recall, but it has security implications which I'm not going to  
| accept.

We already did a new version of Smart Presence back then, that does not
trust roster data as the first version did.

When we wrote the first version we didn't know about the aspect
that allows clients to modify subscription data, and I still think
that's a design mistake in RFC 3921 that should be fixed. But other
people call it a feature.

We accepted to call it a feature and changed Smart Presence accordingly,
so the current version does not use roster data from the client, but
plugs into the stream of subscription events as they occur. I wonder
if you noticed that change. It means fumbling with the roster data
cannot corrupt the distribution plan.

That new version wasn't taken in consideration by the council apparently.

| 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.

Considering how specific and informed the council decided upon the
fate of our efforts, it left a demotivating impression. But maybe
it had indeed nothing to do with politics. Should Multicast make it
into XMPP, then XML is the only thing left really worth criticizing
about XMPP. That's a huge leap forward, even if a vast majority of
people has a hard time understanding there is a problem at all.
Factually it's there. I look forward to removing all the criticism
from websites once the problem has been addressed. Until then, it's
just honesty to leave it as it is.

| 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.

The junctions doc, which admittedly is some five years old and documented
current practice, does not address the trust issue, simply because the
way it was deployed was manually configured: The admin chose to trust
his uplink. I never said this has to be anybody else's trust model,
but you can't say it's not one of possible trust models, even for XMPP.

By the way, we used them for public information only: Newscasts, large
scale chat events. You can easily monitor correctness by opening up a
second chat window on a different server. Introducing false information
is as risky as mirroring unix source codes and introducing malware in the
process. Somebody will figure it out.

There are better solutions to the trust issue, like trust metrics in the
social network, but they are so terribly much more complicated and keep
you from getting started with anything. Once defined and deployed a
better trust plan can be applied to an existing multicast strategy,
if designed that way.

| 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.
| 
| Because they pass through a different code-path, there is a stronger  
| likelyhood of bugs.

Okay. Implementation detail to handle.

| > 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.

Hey wait. You can't say email has been multicasting. It has NOT.
There have been relaying servers in UUCP times, but that's history,
and they were hardly ever consciously used for traffic optimization.
NNTP is a protocol that has been sort-of multicasting successfully,
if you want to dig into the past. And yes, NNTP works pretty well -
getting articles distributed worldwide in near real-time. How?
Because of a tree distribution structure!

| 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  

IRC has been doing multicast for decades, yes. Coming up with the
political issue of IRC not being like XMPP is completely besides the
point. Just because XMPP is better at mostly everything else, it
doesn't mean it doesn't have this one lesson left to learn from IRC.

Original IRC even *was* federated, but the database model didn't
allow for that to stay that way. That's why I started working
on the "next IRC" since the 1990 IRC War. You describe exactly the
point why I started designing PSYC. The difference is, I intended
not to throw away the one major achievement of IRC in the process.

| I'm sending you this using SMTP, and not X.400 (my mailserver *DOES*  
| speak both).

No comment.



More information about the Standards mailing list