[Standards-JIG] XMPP bandwidth compression

Matthew A. Miller linuxwolf at outer-planes.net
Wed Jun 30 22:49:25 UTC 2004


I believe he was referring to the XMPP:e2e Internet Draft currently 
wending its way through the IESG.  If I understand things correctly, 
following either of Boyd's suggestions would require redrafting the 
XMPP-WG charter.

In either case, I firmly believe it would be in everyone's best 
interests to either submit a new Internet-Draft to the IETF (probably 
preferred) or JEP to the Council.  Let's not fall into the trap of 
feature creep, especially for things nearly completed.


-  LW

Stephen Pendleton wrote:

> Actually, I was going to ask the same thing. If Antepo has it worked out and
> is willing to open their spec then we could use their experience as a basis
> for going forward. 
> 
> When you mean the XMPP End-to-End Encryption RFC, are you refering to
> JEP-0116? I was going to suggest just creating another JEP to cover the
> compression features.
> 
> Thanks
> 
> -----Original Message-----
> From: standards-jig-bounces at jabber.org
> [mailto:standards-jig-bounces at jabber.org] On Behalf Of Fletcher, Boyd C.
> J9C534
> Sent: Wednesday, June 30, 2004 6:13 PM
> To: jean-louis.seguineau at antepo.com; Jabber protocol discussion list
> Subject: RE: [Standards-JIG] XMPP bandwidth compression
> 
> 
> have all thought about releasing the specification of exactly how you did it
> so that we can all make use of it so our systems are interoperable?
> 
> What does everything think about starting up a small working group to small
> definitely the XMPP compression problem? 
> 
> I would think we would need to either update the XMPP:Core RFC or add it to
> the XMPP End-to-End Encryption RFC (which might be easier).
> 
> Peter, what do you think?
> 
> boyd
> 
> 
> 
>>-----Original Message-----
>>From: standards-jig-bounces at jabber.org
>>[mailto:standards-jig-bounces at jabber.org] On Behalf Of 
>>Jean-Louis Seguineau/EXC/ENG
>>Sent: Wednesday, June 30, 2004 5:50 AM
>>To: standards-jig at jabber.org
>>Subject: Re: [Standards-JIG] XMPP bandwidth compression
>>
>>Joe,
>>
>>You've certainly expressed it better than I could. This is
>>just what we do, but in java ...
>>
>>Jean-Louis
>>
>>P.S. Funny how often we think along the same lines :)
>>
>>-----Original Message-----
>>
>>Message: 9
>>Date: Mon, 28 Jun 2004 18:08:48 -0600
>>From: Joe Hildebrand <hildjj at gmail.com>
>>Subject: Re: [Standards-JIG] XMPP bandwidth compression
>>To: Jabber protocol discussion list <standards-jig at jabber.org>
>>Message-ID: <82777bea0406281708644db513 at mail.gmail.com>
>>Content-Type: text/plain; charset=US-ASCII
>>
>>Why wouldn't a fairly-stock compression algorithm compress
>>XMPP nicely?  *Lots* of repeated tags, namespaces, etc.
>>
>>I can imagine using zlib to do streaming compression.  Call
>>Z_FULL_FLUSH or Z_SYNC_FLUSH after each stanza.  As a matter 
>>of fact, we could define a stream feature that did just that, 
>>with no TLS. 
>>Negotiate zlib compression, and start a new stream.  Call 
>>Z_SYNC_FLUSH after the stream:stream on each side, and then 
>>after each stanza (or series of stanzas, if you know you're 
>>going be sending many at once).
>>
>>ref: http://www.gzip.org/zlib/manual.html
>>
>>It's important not to use something like wbxml
>>(http://www.w3.org/TR/wbxml/) since in order for the
>>compression to be good enough, you have to know all of the 
>>potential schema at the beginning of the stream.  
>>Extensibility would suffer greatly.
>>
>>On Mon, 28 Jun 2004 15:07:10 -0400, Bob Wyman <bob at wyman.us> wrote:
>>
>>>Boyd Fletcher wrote:
>>>
>>>>One problem would be for those users who do not want to
>>
>>or can not
>>
>>>>use TLS. Sometimes the TLS overhead both in extra data
>>
>>sent and the
>>
>>>>reconnect problems can be too much.
>>>
>>>        Whether or not TLS is available, this approach is
>>
>>probably not
>>
>>>the best for Jabber/XMPP use anyway.
>>>        The problem is that compression is expensive and often can't
>>
>>deliver
>>
>>>useful results on small payloads. Thus, in a mixed use Jabber
>>>connection, where you're like to have both tiny chat packets like 
>>>"brb" as well as
>>
>>large
>>
>>>PubSub.com packets that send entire news items, you're
>>
>>going to end up
>>
>>>increasing the size of your chat packets while decreasing
>>
>>the size of
>>
>>>the large packets. The tradeoff might not, however, be
>>
>>positive. Also,
>>
>>>the per-packet cost will increase because of the compression costs.
>>
>>Compression
>>
>>>costs, combined with the cost of doing TLS encryption (if desired),
>>>might make the cost of preparing packets prohibitive. You 
>>
>>should also
>>
>>>consider that most compression schemes will prevent you from doing
>>>"streaming" use
>>
>>of
>>
>>>data (i.e. working with partial results rather than buffering
>>>everything before you do anything with even the first bytes 
>>
>>in a message.)
>>
>>>        The problems of high-transaction rate servers are
>>
>>not quite so
>>
>>>simple that they can be solved by simply saying: use RFC 3749...
>>>
>>>                bob wyman
>>>
>>>
>>>
>>>
>>>_______________________________________________
>>>Standards-JIG mailing list
>>>Standards-JIG at jabber.org 
>>>https://jabberstudio.org/mailman/listinfo/standards-jig
>>>
>>
>>
>>
>>
>>--
>>Joe Hildebrand
>>
>>
>>------------------------------
>>
>>_______________________________________________
>>Standards-JIG mailing list
>>Standards-JIG at jabber.org 
>>https://jabberstudio.org/mailman/listinfo/standards-jig
>>
>>
>>End of Standards-JIG Digest, Vol 5, Issue 31
>>********************************************
>>
>>_______________________________________________
>>Standards-JIG mailing list
>>Standards-JIG at jabber.org 
>>https://jabberstudio.org/mailman/listinfo/standards-jig
>>
>>
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> https://jabberstudio.org/mailman/listinfo/standards-jig
> 
> 
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> https://jabberstudio.org/mailman/listinfo/standards-jig



More information about the Standards mailing list