[Standards] Council on Stanza Repeaters without Multicast

Dave Cridland dave at cridland.net
Thu Apr 3 13:47:04 UTC 2008


On Thu Apr  3 13:00:33 2008, Carlo v. Loesch wrote:
> 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.
> 
> 
The trouble is I don't see repeaters as being a swiss army knife. I  
see it as being a hammer. Unfortunately, I'm not yet convinced that  
all our problems are soluble by hitting them.

> 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.
> 
> 
No, "is  superior" is opinion. "Results in fewer stanzas" is fact.  
"May result in an increase in RTT delays" is also a fact. "We have no  
idea how bandwidth is affected" is also a fact.

> 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.
> 
> 
No, if a client specifies subscription state data in a roster-set,  
it's ignored. There's plenty of other, more interesting, problems to  
worry about.

> | 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.
> 
> 
Actually, no. Stating that any technical decision, if not in your  
favour, must be politically motivated is a cheap argument to make,  
and is most plainly dishonest, and a pathetic attempt to apply  
political pressure onto a technical decision. I cannot possibly  
comprehend how you can call that strategy "just honesty", and by  
directly attacking my integrity prior to even waiting for the  
decision, you've drastically lowered my opinion of you.

> | > 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!
> 
> 
SMTP allows for multiple recipients for a given message, and I  
believe that some servers do indeed collate these such to reduce DATA  
commands, by identifying the potential for sharing domains, etc. I  
have a vague feeling that zMailer is one such. Most just push per  
domain.

Interestingly, we could do the same with XMPP with Repeaters, but I  
suspect it's simply too complex to implement realistically, and we'll  
end up with one Repeater per domain. Or per domain with more than N  
targets, anyway. Where we don't yet know what N might usefully be.


> | 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.
> 
> 
Yeah, IRC was federated back when everyone ran open relays for SMTP.  
Its federation didn't scale, and wasn't secure.


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

Yeah, because the obvious comment to make doesn't really promote your  
argument, does it?

SMTP (and XMPP) operate with an open flat federation. Basically, this  
means that for me to send you an email requires no prearrangement -  
you publish your MX records, I connect to the server specified, and  
we're talking. For XMPP, it's SRV, but that's simply "Super MX", so  
no big deal.

NNTP and PSYC both operate on a closed heirarchical federation (PSYC  
is more complex, overlaying multiple fedreation strategies). This  
uses prearranged uplinks in order to handle load. It's not the only  
method of handling load, but it's a simple one to do. This means that  
although I can talk to anyone via these protocols, I need to  
initially arrange to connect to the network. As a protocol increases  
in value, joining this network increasingly becomes a matter of cost.  
(Hence a newsfeed costs actual money. PSYC is, as yet, free).

X.400 operates on a closed flat federation - anyone who I want to  
send mail to via X.400 I need to prearrange with in advance, setting  
up agreements. There's no spam on X.400, because the spammers would  
have to arrange to exchange mail with their targets in advance. It's  
also got a few handy properties that make it highly sought after in  
some industries. Yet hardly anyone uses it.

There are other open flat protocols, too - although HTTP doesn't do  
any meshing, the WWW as a whole is also an open flat federation. I  
understand that the WWW is quite popular these days.

You may be excused for thinking that the style, open/closed,  
flat/heirarchical, of federation has obvious impacts on  
deployability, and that this makes a difference to the utility and  
therefore popularity of the protocol.

Doubtless I'm just being political here, but I don't think that's a  
baby I want to throw out with the bathwater.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list