[Standards-JIG] XMPP bandwidth compression

Fletcher, Boyd C. J9C534 Boyd.Fletcher at je.jfcom.mil
Fri Jul 2 21:14:22 UTC 2004


> -----Original Message-----
> From: Bob Wyman [mailto:bob at wyman.us] 
> Sent: Friday, July 02, 2004 10:41 AM
> To: Fletcher, Boyd C. J9C534; bob at wyman.us; 'Jabber protocol 
> discussion list'
> Subject: RE: [Standards-JIG] XMPP bandwidth compression
> Boyd C. Fletcher wrote:
> > So unless someone writes a jabber server that uses the encoded form 
> > internally, wouldn't you still have to convert the encoded 
> form back 
> > to XML and the binary data into base64 so that the XML 
> router and XMPP 
> > server components could process it?
> 	Yes, No and Maybe...
> 	Servers need to do at least minimal parsing of the XML 
> stanzas that they receive in order to determine what to do 
> with them. In theory, Fast Infoset would make that parsing 
> faster and less CPU intensive at the same time that it 
> reduced the number of bytes sent over the network. This is a 
> good thing. However, if a server was to receive a stanza over 
> a Fast Infoset stream, yet needed to forward that stanza over 
> a stream that was conditioned for XML traffic, it would have 
> to convert the Fast-Infoset data to XML prior to forwarding 

since at its core, a jabber/xmpp server is an XML router I would think that all packets would have to converted to XML, processed (routed), and then scheduled for delivery which may or may not be over another compressed channel.

> it. In this particular case, I'm not sure what the balance 
> would be between the decreased cost of receiving the packet 
> and the increased cost of preparing it for forwarding.
> 	An important question in determining the benefit of 
> using Fast Infoset will be: "How much of the incoming stanzas 
> does the server parse?"

I believe it parses the entire stanza though it only acts on the certain tags (iq, message, presence, etc...) the rest are either delivered to clients or server components.

> If the server parses the entire incoming stanza (not always 
> necessary), then it is likely to benefit more from Fast 
> Infoset then otherwise. Also, there is a question about 
> whether the server constructs outgoing stanzas from the 
> result of parsing the incoming stanzas or does it simply 
> "copy" chunks of the input into the output. If the stanzas as 
> reconstructed from the internal form (i.e. the result of 
> parsing) then Fast Infoset will produce a win. If the server 
> simply copies text from the incoming stream, then Fast 
> Infoset will offer less of a gain. (i.e. it all depends...)
> 	Some cases would result in large wins. For instance, if 
> both the streams coming into the server and those leaving it 
> were conditioned for Fast Infoset, the server would benefit 
> from the lower bandwidth on both sides of the connection as 
> well as the reduced parsing and preparation time in the 
> server. If, for instance, people decided that they wanted to 
> do things like voice-over-jabber (which would be *really* 
> ugly today...) one might expect that you would have Fast 
> Infoset streams on both sides of the server -- using XML for 
> such an application would be "possible" but highly unlikely 
> and probably highly discouraged due to the cost, latencies, etc.

good point and I can see how FI would decrease the routing time but one of my worries is that if the server was getting traffic in both XML and FI it would have to have essentially two pipelines (to maintain the efficiency of FI). This would add considerable complexity to the development of a server. The block compression solution doesn't suffer this potential problems.

> 	Some other cases where Fast Infoset conditioned streams 
> might make sense might include: 
> 	1. Server-to-server streams where high-volumes of 
> traffic need to be handled. 
> 	2. Using Jabber as a transport protocol for 
> data-intensive applications. (i.e. not simple chat, MUC, etc.)
> 	3. Communicating with bandwidth-constrained or 
> cpu-constrained devices like cell-phones, various remote devices, etc.
> 	In any case, *IF* support was provided for conditioning 
> streams to pass Fast Infoset, one would not expect Fast 
> Infoset to be the default conditioning. If it was supported, 
> I assume that normal text-XML would always be the default 
> stream conditioning and Fast Infoset would only be used on 
> request and where it made sense. 
> 	This whole business of using alternative encodings and 
> trying to address the limitations of XML encoding is a 
> complex one that is gaining quite a bit of attention in other 
> quarters. It will be interesting to see, I think, what we've 
> learned and how we change what we do (or if we change) in the 
> next few years...
> 		bob wyman

More information about the Standards mailing list