[Standards-JIG] proto-JEP: Smart Presence Distribution

Dave Cridland 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 
> compression.

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