[Standards] XEP-0047 (Flow rate control for IBB)

Chris Mullins chris.mullins at coversant.net
Thu Jul 19 17:43:34 UTC 2007

Our client, SoapBox Communicator, makes extensive use of IBB.

We also went with an IQ based IBB mechanism that uses flow control. 

We allow the sender to have a configurable number of IQ Packets to be
"in the network" (e.g. the sender hasn't yet gotten a response) at a
time, and when that limit is reached, no more data is sent until a
response is received. 

This made it preferable to the message based bytestreams, which had some
major congestion issues around them, especially if the two endpoints
were on very asymmetric connections. 

The IQ Packet we use inherits directly from an IQSetPacket, and looks
more-or-less like:

<iq type=set ...> 
  <data sequence='[Some Integer Value]' 
	  streamid='stream this packet is for'>
	Data Being Sent

Chris Mullins

-----Original Message-----
From: standards-bounces at xmpp.org [mailto:standards-bounces at xmpp.org] On
Behalf Of Peter Saint-Andre
Sent: Thursday, July 19, 2007 7:58 AM
To: XMPP Extension Discussion List
Subject: Re: [Standards] XEP-0047 (Flow rate control for IBB)

William Voorsluys wrote:
> Hello,
>> > But, according to the XEP, it is not allowed to include any inner
>> > stanza on the <iq> of type RESULT used as ACK:
>> >
>> > <iq from='juliet at capulet.com/balcony'
to='romeo at montague.net/orchard'
>> > type='result' id='ibb1'/>
>> That's just an example.
>> The RFC allows zero or one child element in IQ result stanzas.
>> This would work:
>> <iq from='juliet at capulet.com/balcony' to='romeo at montague.net/orchard'
>>     type='result' id='ibb1'>
>>   <data xmlns='http://jabber.org/protocol/ibb' sid='mySID' seq='0'>
>> </iq>
> Well, I don't think that XEP-0047 would allow such a response. It is
> not clear in the XEP that a client should reply including a <data>
> element preserving 'sid' and 'seq'. So, most clients wouldn't do that,
> preventing our implementation to interoperate.
> Am I right?

AFAIK, few clients have implemented IBB. We could definitely update the
spec to reflect this kind of acking, which makes a lot of sense IMHO.

Justin, what say you?


More information about the Standards mailing list