On Fri Jul 22 20:41:23 2011, Carlo v. Loesch wrote:
It wasn't my plan to wash dirty laundry five years later, but here
you go..
Yes, it was your plan, that's why you raised it in such hazy terms.
I shouldn't have fed the troll, apparently.
The problem wasn't very theoretical. Matthias Wimmer provided
figures just
months earlier:
http://mail.jabber.org/pipermail/standards/2006-May/011158.html and
http://mail.jabber.org/pipermail/standards/2006-May/011182.html
Over 70% of XMPP messages were <presence/> stanzas of which almost
60% were duplicate resends over the same TCP line. In the grand
total that means that over 40% of stanzas in interserver XMPP
traffic
are redundant. Presumably still today, although I would love fresh
and independent figures.
So you assume that this is, in itself, a problem - one that
compression cannot mitigate sufficiently. I'm just not convinced, in
no small part because nobody seems to complain about the situation. I
don't mean complain about the aesthetics of it, plenty of folk do
that, but the actual server operators don't really seem to care - the
issue of S2S bandwidth simply doesn't appear on people's radars.
We've got a ton of wasteful traffic, actually, around the network,
and none of it seems to cause a problem on the internet. (I think
there's more XEP-0115/XEP-0030 redundant traffic than presence,
actually, but that's just a guess - I base this in part on a guess at
how well that traffic would compress). As far as I can see, no server
operators are complaining that boy, those S2S links chew through
bandwidth.
So this was a theoretical problem at best, at least in 2006, and
that's before we look to consider any mitigations available due to
S2S compression (now far more commonplace than it was in 2006).
Now, it's of interest only in military tactical networks, only it's
all MUC there so presence broadcast from rosters is a non-issue.
We also couldn't believe someone would even suggest stream
compression
can achieve similar savings. Of course it can't, because each of
those 40% redundant stanzas has a different to="" recipient.
Only fixing the protocol does the job.
Yeah, so if you have a bunch of similar stanzas differing only by one
address, that'll nnever compress well, right?
I said then that compression could substantially mitigate the
bandwidth issue, and I demonstrated it as I recall, providing
figures. But they didn't back up your assertion, and you seem to have
conveniently forgotten them. Or maybe you couldn't be bothered, or
you didn't understand.
Later, there was a shift to CPU resources on the server as the real
problem we were apparently trying to solve all along, but I was never
convinced this was actually a problem either.
I didn't even bother to find out if the way we were dismissed
was intentional or out of distraction.
There were a number of reasons given on the mailing list at the time,
in the (very lengthy, as I recall) thread on it. There were a number
of reasons given for similar proposals, too, as they were raised
again. The fact that yours was rejected at a meeting for which the
minutes happened to slip you assume has some deep rooted
significance, verging on paranoia, and you wheel out this frankly
unprofessional attack every now and then.
There have, incidentally, been dozens of attempts at doing this kind
of work, but of course you only count your own. Yours got rejected
because you dared to be an outsider, presumably, rather than on
technical merit. Personally I think they're all a waste of time
compared to other, more pressing, issues.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
