[Standards] Fwd: Meeting minutes 2010-02-15

Philipp Hancke fippo at goodadvice.pages.de
Fri Feb 19 11:35:20 UTC 2010


Dave Cridland wrote:
> Ah, gotcha, you're referring to smart presence distribution, and 
> ironically comparing the reaction of the council. How witty.

;-)

> 1) Without trundling back to the threads to remind myself what the sync 
> liabilities are, I suspect this refers to assymetric rosters, which have 
> remained a problem (and the current resolution is to respond to probes 
> on a case-by-case basis to re-symmetrize - if that's a word - the 
> rosters, which'd entirely break with "smart" presence distribution). 
> Distributed MUC is specifically designed (one hopes) to handle 
> synchronization of relevant state data, and is allowed (specifically) to 
> do all manner of weird things to mitigate the liabilities therein.

Simple chatrooms actually do not need shared state and control. All you
need is smarter routing.

> 2) S2S compression remains our best solution to the matter of 
> inter-domain presence bandwidth, but I'd note we have nothing like the 
> issue that other protocols have. I do have some research I need to carry 
> out on this, but I currently lack the time. In any case, I've read this 
> proposal as an attempt to tackle resilience rather than efficiency as 
> the primary goal, so I'm not convinced this argument is worth revisiting 

In http://mail.jabber.org/pipermail/muc/2010-February/000144.html you say
  "Another distinction between the two approaches is what the core aims
   are - in PSA-style, it's to provide resilience between servers,
   whereas in KD-style, it's largely to reduce redundant message traffic
   from being repeated redundantly repeated."

So you changed your mind already and think reducing redundant redundancy
is no longer worth revisiting?

> for this proposal - but the distinction of trust delegations means 
> different solutions may apply.

One fabulous side effect of "smart" distribution techniques, where you
let the receiving server know who's to receive things from somewhere
is the amazing way how this protects you from SPIM. If the protocol is
all built on unicast, there is hardly a way to detect SPIM. If a
message has to go to all recipients of a certain context, be it a
distributed chatroom or a person's presence, multicast SPIM leads to
unsubscription from the "infected" source whereas unicast SPIM is
obviously illegal and doesn't need to be delivered to the recipient.
So having proper multicast structures actually strengthens trust and
solves not only the effeciency issue.

> 3) I'm not sure exactly what Matt Miller intended to mean at this point, 
> but I suspect it relates to Peter's suggestion to get hard data. See 
> above - on the subject of inter-domain presence (and, for that matter, 
> inter-domain MUC traffic), I'm intending doing some measurements when I 
> can on actual field data, although my measurements based on more 
> theoretical cases seemed to hold up, and the observation that the bulk 
> of bandwidth consumption is highly self-similar, and thus should 
> compress well, is still valid.

No doubt. But those properties also mean that the traffic pattern is
similar to a SPIM or flood attack, making those undistinguishable.

> 4) I understand this proposal is aimed at bringing simple resilience for 
> chatrooms across heterogeneous XMPP networks, very much like IRC. I'd be 
> interested in seeing how you'd do it. I do think you're much better 

lynX will post to muc@ about that.

> placed to find a reasonable solution, and in this case, where trust 

Unfortunately, there is no single "reasonable solution".  The only
common pattern is "at most once per link".

> relationships are explicitly configured, I'd expect the kinds of 
> solutions you're likely to propose to be more acceptable to us annoying 
> folk in the XMPP world.

Beware, I still consider sending stanzas without a 'to' attribute the
most elegant approach ;-)

philipp



More information about the Standards mailing list