[Standards-JIG] XMPP bandwidth compression

Bob Wyman bob at wyman.us
Wed Jul 7 16:35:12 UTC 2004

Boyd C. Fletcher wrote:
> acutally we are having bandwidth issues with XMPP... In the 
> tactical world its not uncommon to have a single 64 Kb/s
> satellite (e.g. INMARSAT) connection over which to run an
> entire ship's (or army unit's) external comms. 
	Yes. As I mentioned in an earlier note, the folk that are currently
feeling the pain of XML size and parsing inefficiencies are those that are
working the extreme cases. i.e. folk like us at PubSub.com who process
millions of messages in real-time, the military folk that Fletcher works
for, or people with tiny remote devices. One of the prices you pay for being
on the edge is that you feel the pain earlier... Nonetheless, I think we
need to be very careful not to rush into standardizing solutions before
we've done some experimentation and let the "bleeding edge" folk figure out
some of the problems before we saddle the main-stream with premature

> I would think a simple block compression algorithm would be
> simpler and more efficient solution and its solves the problem
> of compressing all the data not just the XML tags. 
	The problem is that "it all depends...". In some applications,
you'll get a good size reduction by using standard block compression
algorithms, however, you'll pay by having larger latency and you'll need
more buffer space on at least the receiving end and often the sending end as
well. (Often, the buffer size issue isn't significant -- however, in some of
the Air Force JBI applications, the payloads are very large and thus,
buffering might be a problem.)
	Some applications (those with a high "tag to payload" ratio) will
find that XML-aware compression (like you get from Fast Infoset) actually
beats block-compression systems while providing often faster parsing and
only a minimal "buffer-size" penalty. Other applications will find that the
best solution is to use XML-aware compression on that which is XML (i.e.
tags, etc.) while doing block compression on non-XML data. (i.e. treat the
XML + payload as interleaved streams of data with distinct compression
methods for each "stream" of data.
	There is no "silver bullet" here. The extreme applications that are
feeling the size and parsing speed issues vary greatly in their
characteristics and in the solutions that work best for them. We need to
come to understand the range of problems, solutions, and compromises. This
will take some time.

		bob wyman

More information about the Standards mailing list