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

Dave Cridland dave at cridland.net
Fri Feb 19 12:41:21 UTC 2010


On Fri Feb 19 11:35:20 2010, Philipp Hancke wrote:
> 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.
> 
> 
Depends on what you're shooting for.


>> 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?
> 
> 
Not for presence as a whole, no. For chatrooms, I think it's worth  
looking at, especially if we can gain some levels of resilience out  
of it as well. Sorry, but by trying to combine two arguments, you are  
muddying the waters and confusing two cases which I don't think are  
the same.

Let me also clarify - if we could send IM presence once over a link  
and have fan-out controlled by a foreign domain, I'd be happy with  
it. But I don't think that's a practical option, given that it  
requires greater trust between domains, and prevents various other  
forms of control. FWIW, the same applies to PEP versus general  
PubSub, I think, and these are the same protoclo, but with different  
controls.


>> 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.
> 
> 
Okay, I can go along with this, but I also suspect it's again much  
more of an issue with chatroom (and PubSub) traffic than it is with  
general presence (and PEP), which in general terms has an established  
relationship involved as well. Luckily, this is very similar division  
to the trust issue - fan-out of chatrooms and pubsub nodes is, I  
think a lot more likely to be practical without any changes to the  
trust model we have.


>> 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".
> 
> 
I don't think that's the only goal. I think shared state to provide  
resilience is useful and important too, but I think we can require a  
formalized trust relationship there.


>> 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 ;-)

Sure, from some perspectives. I just think that thanks to various  
other features of the architecture, doing this blindly will lead to  
problems.

But I'm pretty sure you understand my perspective on this - you  
pointed out in private IM that "the moderator which uses a slave  
needs different information from the master than the average user" -  
things like jid disclosure, etc, may indeed mean that a simple  
master/slave isn't suitable for all cases, and we'll need to consider  
that carefully.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - 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