Subject: Re: RE: [lemonade] compression

From: "Xiaohui Fan" <[email-masked]>
Date: Mon, 20 Mar 2006 13:35:01 +0800

Actually there are very few handsets supporting TLS in the market. Some terminals support SSL but donot implement compression mechanism.

And I believe it is not necessary to compress commands. Some commands are very short and the compression cannot have 
obvious enhancement on it, while on the other side, the compression computing on each command will increase the cost
of battery. 

So object compression is more realistic and economic on mobile phones.

======= 2006-03-20 11:43:18 you wrote in email：=======

>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
>
>> 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.
>> >
>> > 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.)
>
>> 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.
>
>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
>
>_______________________________________________
>lemonade mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/lemonade
>
>
>_______________________________________________
>lemonade mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/lemonade

= = = = = = = = = = = = = = = = = = = =
　　　　　　　　
				 
Best Regards 				

Fan Xiaohui

Product Development Division 
R&D CENTER
CHINA MOBILE COMMUNICATIONS CORPORATION (CMCC)
ADD: 53A, Xibianmennei Ave.,Xuanwu District,Beijing,100053 China
TEL:+86 10 66006688 EXT 3137
FAX:+86 10 63600340
E-mail: [email-masked]
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade