[Standards] Fwd: Re: [Simple] MSRP congestion control issue when using relays

Dave Cridland dave at cridland.net
Thu Dec 13 12:42:08 CST 2007


On Thu Dec 13 16:51:35 2007, Peter Saint-Andre wrote:
> http://www1.ietf.org/mail-archive/web/simple/current/msg07579.html
> 
> 
Hmmm. So we're stripping forwarded messages... Yes, that's the one.


> > I'm wondering if people think that a similar thing might affect  
> XMPP, if
> > you change "relay" to "XMPP Server". Is it possible, potentially,  
> for
> > Calin and Donald, by exchanging sufficient data sufficiently  
> slowly, to
> > choke up an XMPP s2s link? And if so, what do we do about it?
> 
> Theoretically this *might* be a problem with in-band bytestreams
> (XEP-0047), which in a way is similar to MSRP. But you could send
> "large" stanzas using plain old XMPP, too, so I don't think it is
> (theoretically) limited to IBB. However, whether this theoretical
> problem has any practical significance is another question.
> 
> 
Well, you'd just need to send sufficient stanzas, and/or sufficient  
data, enough to overwhelm Donald, whether on purpose or by accident.

> In particular, using Rémi's options, I think that if an XMPP server  
> were
> in this situation it:
> 
> 1. would not put the s2s connection on hold -- that's crazy!
> 
> 
Right, with you there.


> 2. would not discard the stanza, especially not for IQ stanzas but
> probably not for message stanzas either
> 
> 
Right, I don't think that's desirable.


> 3. would not queue the stanza for later delivery since the  
> recipient is
> online and has an available resource
> 
> 
No, I think Rémi is describing buffering, which is going to happen  
somewhere unless you outright refuse the stanza. The MSRP people have  
decided this is the way to handle things, but ultimately, this  
implies that an XMPP server has infinite storage (whether in RAM or  
disk), with which to buffer.


> 4. would return an error to the sender (e.g.,  
> <recipient-unavailable/>)
> 
> 
But won't this mean, effectively, that messages and/or data are lost?  
In this case, I'm assuming Donald is legitmate - if Donald is  
deliberately throttling his c2s link, in order to create a DoS, then  
we don't care, of course.

What we want to do here - I think - is throttle the sender, and only  
start to reject stanzas if the throttling is ignored. (Perhaps  
because it's unsupported).


> > And perhaps more importantly, has anyone ever seen this in the  
> wild?
> 
> I have not seen this in the wild.

Well, that's something, then - it means we needn't rush to a solution.

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