[standards-jig] IBB: Making it all "go"

Tijl Houtbeckers thoutbeckers at splendo.com
Fri Apr 11 02:32:35 UTC 2003

Rachel Blackman <rcb at ceruleanstudios.com> wrote on 11-4-2003 4:24:05:
>Of course I've used HTTP to open a bytestream. :)  But you're actually 
>sort of making my point for me; <iq/> is the HTTP header data, which I 
>send and receive back, and thus have negotiated a stream.  <message/> 
>is the stream itself.
> <snip>

I see my comparison with HTTP has been taken very literary. I didn't 
mean it as such. HTTP can rely on TCP for proper flowcontrol, IBB can 

I still have very serious doubts on the extra overhead <iq/> gives, nor 
do I think <message/> will have any sicnificant speedadvantage over 
<iq/>. (Since you don't have to wait for every ack, eg. you can choose 
to send a surthen number of packets to create a buffer. The many small 
ack packets will help you keep this buffer filled yet with a minimum of 

I know there are probably some cases in wich it would be preferable not 
to ack every packets, but the disadvanteges are so insicnificant they 
are hardly worth mentioning. As pointed out, in *bandwith* terms a 
"bloated" message stanza will probably take up just as many bytes as an 
<iq/> + <iq type="result"> (the "ack"). Let alone if you you use 
<message/> and want to ack all your packets (wich in many cases you 
will want to). 

>Hopefully that clarifies what I was trying to say.   (Look, I found 
>more pennies!  Have two!) :)

I understood properly before, I just went a bit too far with my own 
example. But thank you anyway (and I can always use some extra pennies 

Robert Norris <rob at cataclysm.cx> wrote on 11-4-2003 3:53:10:
>> PGM seems to feel though that "acks" make the protocol so seriously 
>> flawed it can't be used at all. I'd like to know the opinion of the 
>> rest of the community and council on this. 
>You asked ;)
>For just acks, my preference would that acks are not required. The use
>(and frequency) of acks would ideally be a negotiated option - a kind 
>of measure of stream reliability, if you will.

You speak of a "preference". Comparing <iq/> to <message/> what would 
be prefered? about the same bandwith but more packets and an ack for 
every packet. about the same bandwith for and less packets if you 
choose to turn them off or more bandwith and the same number of packets 
if you turn them on? 

To make myself clear, I'm trying to find out why the thought of ack for 
every packet scares so many people.. *is* it the bandwith, or is it 
something else? Higher server load? Or is it just that it "doesn't feel 

I do count any extra options of negotiating frequency as complicating 
the JEP, IMHO unnecisarly but I'm sure not everyone agrees on that :) 

>I think your analogy to HTTP is somewhat flawed. A HTTP session has two
>distinct parts - the setup, paramater exchange bit, and the actual 

The actual data (with HTTP) wrapped in TCP packets. Not the case with 

>We have similar mechanisms in Jabber - we've traditionally used <iq/>
>for exchange of meta-information (paramaters, etc), while using
><message/> for data transfer.

Wich as we "discovered" is a flawed mechanism, espc. in a session based 
enviroment because the delivery sematics of message stanzas are 
different from iq stanzas by default, and currently there is no fix 
available to fully solve this problem.. 

>It seems to me if we're trying to draw an analogy to HTTP, then placing
>both the stream metadata and the actual data in <iq/> is equivalent to
>placing the data proper in the HTTP header.
>> Maybe a name change to "reliable IBB"?
>Why require it to be reliable? 

Because then the scope of the JEP will be clear. Or "Simple reliable 

>As I said above, provided the mechanisms
>to select the desired reliability on a per-application basis.

If JEP 22 and 23 are in standards track, yes. But at practically the 
same costs as <iq/>. For a purpose I still do not fully see. If you 
want low latency you'll send smaller packets, but then you'll want all 
your packets acked for good flowrate control. If you don't care about 
latency just send huge packets. If you want something inbetween, send 
something inbetween. The only real advantage I could see is if you want 
no reliability at all, wich IMHO can be done in another JEP, just like 
(to make more anologies) TCP and UDP are seperated. 

>> If anyone can point out something that is not solid about the JEP as 
>> it is, please do so. Perhaps giving in to a questionable 
>> philosophical argument and saying: "allright, if you want to use the 
>> message stanza we'll wait another few months/years" is a path of 
>> even less resitance ;) 
>My other concerns about using <iq/> for data exchange is that it sets a
>bad precedent for the future direction of the protocol, and brings into
>question the worth of the <message/> stanza. At the moment, things are
>very simple - <message/> is for data exchange, <iq/> is for metadata
>exchange and negotiation.

Simple or not, I pointed out the problems we have with this above.

>I agree, we need facilities to add reliability to <message/> stanzas.
>However, I don't beleive that IBB will be delayed significantly just
>because these facilities don't exist. There's nothing stopping them
>being developed in parallel, and indeed, we already have someone 
>working on such a JEP.
>(I also note that the existing mechansims (jabber:x:event and
>jabber:x:expire) are enough to get an initial version of this protocol
>working, in a way that can be extended easily later. If done in this
>way, IBB does not even have to depend on these reliability facilities).

x:event and x:expire, as explained on this list, do NOT fully cover the 
problems with using the <message/> stanza. 

>I also don't see the urgency for IBB - we have one potential 
>application for it (JEP-0052, still experimental) and we have a 
>solution that can perform roughly the same tasks (JEP-0065, one vote 
>needed before it goes to Draft).

Since when are JEPs only needed when more then one excisting JEP 
already depend on them? Comparing JEP-0065 to IBB is... well, let me 
put it like this: not a good reason to stop us from moving ahead on 

>I'll state here for the record that if JEP-0047 were to go to Council
>for a vote in its current state, I will vote -1 because I don't beleive
>that its the right way to do it (gut feeling is a wonderful thing), and
>it sets a bad precedent (as well as bringing into question the
>long-term utility of <message/> as more than just a IM facility).

I have a gut feeling too, namely that the philosopical <iq/> vs. 
<message/> question is most dominant in both your and PGM's decision to 
turn down JEP-0047 as it is. I have my questions as to how *far* the 
council should go in making JEP authors commit to future protocols and 
future implementations for something thay want here and now. But if the 
council does not agree with me on that, I guess there is not much I can 
do about that, expect follow council member PGM's recommendation and go 
the way of properiety extenstions that *do* work. 

>However, I will commit right now to implement (in jabberd2) any message
>reliability mechanisms as soon as they are ratified by the Council (or 
>a few days after). I would hope that having a server that implements 
>the necessary pieces would help to speed adoption.

Now matter how you twist or turn it, that's one good thing to come out 
of this discussion for everyone, since this hopefully means future 
applications can properly use the message stanza and benifit a lot 
(more) from it. 

Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands

More information about the Standards mailing list