[Standards-JIG] XMPP bandwidth compression

Fletcher, Boyd C. J9C534 Boyd.Fletcher at je.jfcom.mil
Wed Jun 30 23:19:24 UTC 2004


well the XMPP:e2e specification isn't moving very fast from what I hear and its related to compression so why not? 

I'm not sure a JEP is the best approach for the same reason e2e is RFC bound. It should be a core feature of the XMPP suite and not an enhancement like MUC and PubSub.

Perhaps Peter St. Andre could bounce the idea off the XMPP WG Chairs?

boyd


> -----Original Message-----
> From: standards-jig-bounces at jabber.org 
> [mailto:standards-jig-bounces at jabber.org] On Behalf Of 
> Matthew A. Miller
> Sent: Wednesday, June 30, 2004 6:49 PM
> To: Jabber protocol discussion list
> Subject: Re: [Standards-JIG] XMPP bandwidth compression
> 
> 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
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> https://jabberstudio.org/mailman/listinfo/standards-jig
> 
> 



More information about the Standards mailing list