[Standards-JIG] proto-JEP: Smart Presence Distribution
dave at cridland.net
Thu Jun 1 14:29:04 UTC 2006
On Thu Jun 1 14:21:41 2006, Carlo v. Loesch wrote:
> Dave Cridland typeth:
> | Is this based on page hits?
> Based on irony.
So basically, you're just making insulting remarks about the members
of the list again.
> | I think people would be more immediately interested in reducing |
> either octet count or packet count. I doubt stanza count is an |
> important metric for scalability. Packet count is basically reduced
> It's the statistics I was given so far, and I find them
> already convincing, but if you want harder facts, we could
> gently ask Matthias to sit down and count how many octets
> those redundant presence stanzas sum up to.
Well, unfortunately, I can't ask anyone to give me the server traces
to analyse myself, so I can't actually tell you even what Matthias's
figures are showing. They're showing that there are lots of presence
stanzas, of course, but I'm not clear if they're saying that your
proposal would reduce traffic by 5% or 95%.
Kevin Smith says it too - if you think there's a gain to be made,
then demonstrate it with actual figures.
> | Your first proposal did the first, but at the risk of privacy,
> and | your second is simply a representational change - it'll work,
> to a | degree, but I think overall the gains will be small
> post-compression, | if they exist at all.
> Yes we know what you think of ~50% less stanza packets.
> Everyone has his beliefs, you believe in the blessings of
Yes. I base these beliefs on experience of stream-level compression
and its effects on a number of email protocols for a couple of months
after putting a considerable amount of time into putting in full
coverage for a range of extensions designed to maximize efficiency.
I agree with Kevin, though, that we need more figures and less talk.
> We're not ignoring it, but so far noone found the time to draw up
> a protocol scenario with 50 people on the other side of the line.
> Version A with 5 presence changes "broadcast" to those 50 people.
> Version B with 4 presence changes after one "broadcast" to 50
> Then see what compression algorythms make of that.
Also, while you're at it, you can tell me what percentage of people
have 50 buddies on remote servers, and what percentage of servers
have these 50 buddies, and tell me what the projected savings based
on real world data actually are without compression.
Those questions can't be answered except by server admins, so perhaps
the solution might be to write some software to analyze the streams,
and ask the server administrators to run the software on real data,
and publish the results.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards