Subject: Re: [lemonade] compression

From: "Burger, Eric" <[email-masked]>
Date: Sat, 18 Mar 2006 07:29:42 -0500

Arnt did an excellent job collecting actual data on the value of transport layer compression and application layer compression.

The counter argument I hear (and I'm hard of hearing, so I may be wrong) is that transport layer compression might, under certain circumstances, use more MIPS.

It would be really helpful if someone could get _data_ on CPU use.

Besides being useful data to help solve this problem, this data could result in a conference or journal paper (hint). If anyone is interested in glory, contact me off-line.

 -----Original Message-----
From: 	Ned Freed [mailto:[email-masked]]
Sent:	Fri Mar 17 14:25:11 2006
To:	Dave Cridland
Cc:	Enhancements to Internet email to support diverse service enivronments; Arnt Gulbrandsen; Ned Freed
Subject:	Re: [lemonade] compression

> On Fri Mar 17 14:49:33 2006, Ned Freed wrote:
> >> a) They're free to use alternate compression algorithms which don't
> >> make sense for streaming data, or are relatively expensive, since
> >> they're operating on a-priori known immutable data. So an
> >> LZIP-a-like
> >> could be made to use a Burrows-Wheeler Transform, or an Arithmetic
> >> Coding with prearranged model presets, or any number of other
> >> relatively expensive algorithms.
> >
> > Nothing prevents alternate compression schemes from being used in
> > TLS.
> > In fact you should be able to switch compressions on the fly by
> > renegotiating. This is actually better than LZIP-like schemes
> > because it
> > could be initiated by the server, which is in a better position to
> > know what compression would be best for a particular message.
> >
> > But this is all theoretical and IMO likely to stay that way.. I
> > doubt very much
> > that anyone will actually do such things - the added complexity is
> > just not
> > worth it.
> >
> >
> Wouldn't the compression renegotiation involve an extra round-trip?

Perhaps - I don't know enough about the protocol specifics in TLS to say. But
if choice of compression really matters to this extent, I doubt if the extra
round trip is going to matter that much.

> And in any case, there's obvious mechanisms which are LZIP-like, but
> involve the server selecting a compression algorithm. HTTP already
> has this kind of mechanism. I think this stands in favour of
> LZIP-like mechanisms, to be honest.

I disagree, but I also think this entire thing is so far out there it is
irrelevant.

> An uber-compression scheme could, of course, be defined for TLS which
> could not only switch algorithms by a unilateral symbol injection to
> the stream, but switch between models (or dictionaries, etc), thus
> allowing the data character to change when reading attachments and
> messages without degrading the model used for the IMAP protocol
> elements themselves. This is probably equally blue-sky, though.

Actually, I'd say it is less blue-sky than expecting either clients or servers
to analyze data and change compression on the fly. Pushing all the complexity
into the compression engine has some really attractive properties. But as long
as we're compression-method-agile (and any of these schemes can be designed
this way) any work in this space can be deferred.

> >> b) For data that is not compressed by whichever algorithm is used,
> >> the mechanism could return BINARY fetch items instead of LZIP fetch
> >> items, thus avoiding both the expanding data problem, and the
> >> wasteful decompression on the client.
> >
> > The expansion problem should be insignificant if the compression
> > format is well
> > designed.
> >
> >

> True, although again it's less if the entire attachment can be
> compressed in advance, and can be made to be zero with LZIP-like
> mechanisms. (Okay, BINARY is two octets longer than LZIP, and the
> theoretical minimum for a compression algorithm expansion in worst
> case is one octet, assuming an integer number of octets).

> In any case, Deflate is good enough that it compresses most things,
> including JFIF files off digital cameras, etc. Gzipping a 146,525
> octet gzip as a quick test gave me an increase of 55 octets, which is
> comfortably low. (I would hope that's the file header plus one symbol
> per compressed block, less any compressibility of the original file
> header and trailer.)

Yes, I think that's more or less how it plays out.

				Ned

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 18 Mar 2006 22:04:33 +0100

Eric Burger writes:
> Arnt did an excellent job collecting actual data on the value of 
> transport layer compression and application layer compression.
>
> The counter argument I hear (and I'm hard of hearing, so I may be 
> wrong) is that transport layer compression might, under certain 
> circumstances, use more MIPS.
>

I can provide that as a side effect of the further comparison work I'm 
doing (and which I'll post about - the results are surprising). My 
timings won't be very very accurate, though.

The charge has some validity, btw. In certain circumstances, which 
should be odd and unusual but I find myself affected.

Consider compress=deflate and the almost entirely equivalent RFC3749 TLS 
feature. With c=d, the IMAP server author can do some measurements, and 
find out that zlib in its lightest-weight mode provides 97% of the 
achievable benefit (I am not making this up). However, if compression 
is being done by the TLS implementation, _and_ the TLS implementation 
doesn't provide any API to adjust the compression settings, then the 
IMAP server can't do this. Then the IMAP server is bound to spend as 
much CPU on compression as the TLS author saw fit.

> Besides being useful data to help solve this problem, this data could 
> result in a conference or journal paper (hint). If anyone is 
> interested in glory, contact me off-line.

Not me. I speak in public only when there's no escape ;)

Arnt

---

From: Ned Freed <[email-masked]>
Date: Sun, 19 Mar 2006 13:04:40 -0800 (PST)

> > It would be really helpful if someone could get _data_ on CPU use.

The real problem is you can make CPU data say pretty much anything you want it
to say. In the extreme case you can have the server send nothing but
uncompressed blocks. You won't have any compression but the CPU load (on both
ends) will be so low as to be immeasureable.

More generally, it would be entirely feasible for a server to note that a
binary download of some specific media type is unlikely to benefit from
compression and to signal the compressor to enter passthrough mode, thus
avoiding CPU usage on both the server and client. THis could even be done on a
learning basis, or it could be precomputed as messages are inserted. There are
all sorts of possible and more to the point, plausible, designs.

THe key difference in the various proposals is who gets to control what. The
LZIP proposal puts the control largely in the hands of the client and also
dramatically limits the extent to which compression can be used and how
effective it can be. I view all of these aspects of the design as extremely
poor choices - the client is far less in a position to know when compression
will or will not be useful than the server is.

One approach that might be interesting would be for the client to give some
indication to the server as to how it wants compression used. One client might
say "decompression is expensive for me so please use passthrough unless there
are major benefits". Another might say "bandwidth is my concern, compress
whenever there is benefit". These sorts of controls could easily be included in
the c=d proposal.

But given that CPU statistics are almost certainly going to be done on an
all-or-nothing basis, and this doesn't have to be (and probably shouldn't be)
how a real implementation would work, I view any such data as a red herring,
regardless of the results it shows. (I would also expect any test that involves
downloading of a large object undergoing compression to show no significant
differences between the various proposals - and if it doesn't the tests are
highly suspect absent a good explanation for the difference.)

> much CPU on compression as the TLS author saw fit.

This is a very good point that should be considered when deciding between
TLS-player compression and c=d. It is especially important given the relatively
small number of TLS implementations servers are likely to use.

				Ned

---

From: "Stephane H. Maes" <[email-masked]>
Date: Sun, 19 Mar 2006 19:43:18 -0800

It seems that a premise is that the server should decide. Interesting different point of view from other cases.

I actually believe that the client should be able to decide when it decides to download something if it wants it have it compressed and how. It needs to be able to selectively select when to compresst. 

Indeed, selective compression provides significant gains (e.g. attachemnt to compress).

In addition, factors outside the protocol consideration or the server knowledge come into play (like battery state (i.e. is it ok to spend energy decompressing versus getting more data but not having to decompress, user decision (cost vs battery life etc...).

Eventually as was discussed in Beijing, TSL compression is not yet easy to support or expected to be supported on most mobile phones.

So my view is that 1) we need to allow application level selective compression 2) we need to let the client decide 3) it is useful in terms of bandwidth and in terms of battery life to offer this option 40 ...

I have no problem also allowing TLS compression, but in Beijing, the WG rather decided against it...

Stephane

_____
Stephane H. Maes, PhD,
Director of Architecture, Mobile, Voice, and Communications Platforms, Oracle.
Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296
e-mail: [email-masked]
IM: shmaes (AIM/Y!/skype) or [email-masked] (MSN Messenger) or [email-masked] (Google)
 
-----Original Message-----
From: Ned Freed [mailto:[email-masked]] 
Sent: Sunday, March 19, 2006 1:05 PM
To: Arnt Gulbrandsen
Cc: [email-masked]
Subject: Re: [lemonade] compression

> > It would be really helpful if someone could get _data_ on CPU use.

The real problem is you can make CPU data say pretty much anything you want it to say. In the extreme case you can have the server send nothing but uncompressed blocks. You won't have any compression but the CPU load (on both
ends) will be so low as to be immeasureable.

More generally, it would be entirely feasible for a server to note that a binary download of some specific media type is unlikely to benefit from compression and to signal the compressor to enter passthrough mode, thus avoiding CPU usage on both the server and client. THis could even be done on a learning basis, or it could be precomputed as messages are inserted. There are all sorts of possible and more to the point, plausible, designs.

THe key difference in the various proposals is who gets to control what. The LZIP proposal puts the control largely in the hands of the client and also dramatically limits the extent to which compression can be used and how effective it can be. I view all of these aspects of the design as extremely poor choices - the client is far less in a position to know when compression will or will not be useful than the server is.

One approach that might be interesting would be for the client to give some indication to the server as to how it wants compression used. One client might say "decompression is expensive for me so please use passthrough unless there are major benefits". Another might say "bandwidth is my concern, compress whenever there is benefit". These sorts of controls could easily be included in the c=d proposal.

But given that CPU statistics are almost certainly going to be done on an all-or-nothing basis, and this doesn't have to be (and probably shouldn't be) how a real implementation would work, I view any such data as a red herring, regardless of the results it shows. (I would also expect any test that involves downloading of a large object undergoing compression to show no significant differences between the various proposals - and if it doesn't the tests are highly suspect absent a good explanation for the difference.)

> Consider compress=deflate and the almost entirely equivalent RFC3749 
> TLS feature. With c=d, the IMAP server author can do some 
> measurements, and find out that zlib in its lightest-weight mode 
> provides 97% of the achievable benefit (I am not making this up). 
> However, if compression is being done by the TLS implementation, _and_ 
> the TLS implementation doesn't provide any API to adjust the 
> compression settings, then the IMAP server can't do this. Then the 
> IMAP server is bound to spend as much CPU on compression as the TLS author saw fit.

This is a very good point that should be considered when deciding between TLS-player compression and c=d. It is especially important given the relatively small number of TLS implementations servers are likely to use.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Mon, 20 Mar 2006 14:07:34 -0800 (PST)

> It seems that a premise is that the server should decide.

No, the argument is that the server is in a better position to decide.

> Interesting different point of view from other cases.

> I actually believe that the client should be able to decide when it decides
> to download something if it wants it have it compressed and how. It needs to be
> able to selectively select when to compresst.

You're a long way from making a case for this.

> Indeed, selective compression provides significant gains (e.g. attachemnt to

It may offer some CPU gain. I doubt it offers much besides that.

> In addition, factors outside the protocol consideration or the server
> knowledge come into play (like battery state (i.e. is it ok to spend energy
> decompressing versus getting more data but not having to decompress, user
> decision (cost vs battery life etc...).

If decompression is problematic why enable compression in the first place?

> Eventually as was discussed in Beijing, TSL compression is not yet easy to
> support or expected to be supported on most mobile phones.

Even if true - there are other very compelling reasons for getting TLS support
in place - this says nothing about the c=d proposal.

> So my view is that 1) we need to allow application level selective
> compression 2) we need to let the client decide 3) it is useful in terms of
>bandwidth and in terms of battery life to offer this option 40 ...

I think all of these points have been refuted.

> rather decided against it...

Excuse ME, but the WG decided no such thing. IETF decisions are made on the
list, not at meetings, and especially not at interim meetings.

				Ned