[standards-jig] IBB: The options

Matthew A. Miller linuxwolf at outer-planes.no-ip.com
Thu Apr 10 17:21:02 UTC 2003


With regards to "delivery semantics" (ACK, offline-ness, etc):

1)  The worst case is that the semantics are more than the data
transferred.  In practicality, the amount of data transferred is almost
always going to be orders of magnitude more than these additional
semantics.  This makes the overhead of those additional semantics  (even
using the non-normative "jabber:x:event" and "jabber:x:expire")
negligible. 

2)  In the worst case of delivery receipt (e.g. confirming every
<message/>), the bandwidth requirements would be true...but would you
really ack every single message?  From experience, this is rarely a
true, or even acceptable, requirement (would you really want your HTTP
or FTP client to *always* send an ACK for each byte transferred to/from
it?).  Usually, this ACK would occur every n-th datagram, to (attempt
to) maintain a higher throughput.

Using <iq/> would force this worst-case scenario every single time, with
no exceptions possible.  Using <message/> (and therefore allowing for a
lower, configurable, ACK frequency), one can use what's appropriate to
the application at hand.  For file transfer, this is quite likely to be
once, for when the transfer is complete.

Also, we've only talked about moving the data transport portion from
<iq/> to <message/>, not the data control portion (e.g. "stream"
negotiation).  There is still the "open" and "close", which should
(must) happen with an <iq/>-style conversation.  And for file transfer,
that may be enough.

With regards to resources, I'm not saying it's not a potential problem. 
But I do say "potential", and not "assured"; we haven't empirically
determined how truly severe of an issue this is for data transport.  If
anything, it requires experimentation.

If it proves to be as truly disastrous (both in behavioral severity
*AND* statistical frequency) as you and others make it out to be, then
I'm sure myself and the others in the "pro-<message/>" camp[1] would be
open to slowing down on this JEP to simultaneously address that issue
(not stopping).


-  LW

[1]  This "pro-<message/>" camp includes at least two very active
Council members (Thomas Muldowney and Peter Millard) who also seem to be
in the "anti-<iq/>" camp (google the list or ping them for
confirmation).  In other words, IBB is *assured* to get two -1 votes if
<iq/> is still used, unless you strongly convince them otherwise.

On Thu, 2003-04-10 at 09:16, Richard Dobson wrote:
> > The fix defines semantics for controlling message delivery.  This can
> > and would be used for more than just IBB, because they would exist as
> > siblings to each other:  a binary data transport within the <message/>
> > envelope, and delivery guidelines for how this particular <message/>
> > should be treated.  When message delivery is finalized, IBB
> > implementations can move to it as immediately or cautiously as they
> > wish.
> 
> IMO it is very bad to finalize IBB before the delivery control fixes, this
> is rushing out an effectively broken protocol IMO.
> 
> > Until this message delivery JEP is ready, JEP-0047 (or whatever JEP
> > becomes inband data transport) can include a non-normative section on
> > using the existing Informational JEP for "jabber:x:expire", and a
> > section on how to act in the case of offline resources.
> 
> But just using x:expire doesnt stop messages going to other resources
> instead of offline storage, which is something which IMO needs to be solved
> first.
> 
> > Simply having message delivery standardized before IBB does not
> > necessarily fix the problem:  it will need to be implemented.  If people
> > have a problem with IBB without message delivery, the motivation to
> > incorporate it will be there.  If they don't, then all this really
> > becomes a small blurb in the history books on Jabber.
> 
> Sure it needs to be implemented before things are fix but you still need it
> to be standardised before IBB, also this is yet another good thing about IQ,
> no changes need to be made to it to get it working, but IMO major changes
> need to be made to the way message works before it can really be used.
> 
> > Using "implementation latency" as an excuse for using <iq/> in a manner
> > it was not designed or intended *will* manifest in yet another Pandora's
> > Box, this being one that cannot be fixed (IMO).
> 
> See below for the question "How is it not designed for it?"
> 
> > The uses for which <iq/> (such as browse, disco, "jabber:iq:last", etc)
> > do not carry the risk that IBB does, because they do not have the two
> > characteristics that IBB possesses:
> > 1)  Generate a possibly large amount of data within each stanza, AND
> > 2)  Generate a possibly large count of such stanzas in a possibly minute
> > amount of time.
> >
> > That behavior is not what <iq/> is designed for, but <message/> is (or
> > at least more so than <iq/)).
> 
> How is it not designed for it?, it has the same limitations as message as
> far as I can see. To transmit the data you have to add a namespaced
> extension to the message, and virtually the same sort of this is done in iq,
> am I missing something here?
> 
> > If <iq/> is used, at best it will double network traffic (which could
> > easily lead to congestion and DOS in its own right), and at worst double
> > the bandwidth usage (if each IBB packet carries a single byte or two of
> > data, and/or the sending end-point attempts to send a number of
> > datagrams that all fail).
> >
> > The biggest benefit gotten from <message/> is a reduction, quite
> > literally in half, of this network traffic.  That is, unless you'd
> > prefer risking a DOS on the server (ruining everyone's experience)
> > instead of risking a DOS on an end-point (ruining that one end-point's
> > experience).
> 
> Ah well im not sure this is entirely true, when adding all the extra
> extensions to message IMO that will create lots of extra bandwidth use, ill
> illustrate:
> 
> Using IQ
> 
> DATA
> <iq to="user1/res" from="user2/res" type="set" id="1">
>     <ibb xmlns="http://jabber.org/protocol/ibb" session="565565">
>         DATA
>     </ibb>
> </iq>
> 
> ACK
> <iq to="user2/res" from="user1/res" type="result" id="1"/>
> 
> Using message
> 
> DATA
> <message to="user1/res" from="user2/res" id="msg1">
>     <body>this is a data transfer packet</body>
>     <x xmlns="http://jabber.org/protocol/ibb" session="565565">
>         DATA
>     </x>
>     <x xmlns="jabber:x:event">
>         <offline/>
>         <delivered/>
>     </x>
>     <x xmlns="jabber:x:expire" seconds="60"/>
>     <x xmlns="http://jabber.org/protocol/delivery">
>         <fixedresource/>
>     </x>
> </message>
> 
> ACK
> <message from="user2/res" to="user1/res">
>       <x xmlns='jabber:x:event'>
>         <delivered/>
>         <id>msg1</id>
>       </x>
> </message>
> 
> Now ive added an extra example protocol in for delivery control as an
> example of the extra bandwidth that is being taken up by all these
> extensions just to make message perform in a way iq does already, now this
> demonstrates that actually more bandwidth is used up by the message sending
> mechanism than iq is using up. I still think IQ is a much more elegant
> solution.
> 
> Richard
> 
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
-- 

Matt "linuxwolf" Miller
JID:	linuxwolf at outer-planes.net
E-MAIL:	linuxwolf at outer-planes.net

- Got "JABBER"? (http://www.jabber.org/)




More information about the Standards mailing list