Subject: RE: [lemonade] Compression: TLS or Application-layer

From: [email-masked]
Date: Tue, 28 Sep 2004 08:48:52 -0500

>From an operator's perspective, any feature which reduces bandwidth
performance is a good thing.  So they would want compression at any
level.
However, TLS connections over GPRS networks tend to be expensive to
setup and difficult to maintain (at least today).
Another consideration is battery drain.  TLS connections tend to be a
big load on the battery because of the computational power required to
decrypt + decompress the stream.  App level compression would improve
battery life, but would still require more power than no compression at
all.

In order to improve the acceptance of email client applications on
mobile terminals we need to make it as user friendly to the common
consumer (90% of the market) as possible.  While enterprises are happy
with TLS compression (or IPSec, MOBIKE, VPN services), allot of
operators today don't offer IMAP/S access to the ISP email server or
require a business/enterprise level contract (not to mention Hotmail,
Yahoo mail, etc.)

If we can add an extension to the server at the application layer the
user/operator doesn't have to be aware that it exists at all.  The
capability is negotiated by the client and server, not configured by the
user.

Another problem is the idea of using IMAP server to client notifications
or IMAP-to-MMS mapping.  In these instances a TLS connection is not
possible and we may want to add compression technology for transporting
email messages over MMS networks or OOB OTA email delivery.

To summarize, I understand you objection and agree if we were designing
for desktop systems, but Lemonade needs to consider both enterprise and
consumer based mobile systems where certain technologies are either
unavailable or unwieldy, requiring us to look at alternative methods to
deliver the same benefits.  If we can come up with something that does
not require compression in order to increase bandwidth utilization, I'm
all for it.
In the end we need to make mobile email as painless as possible, and
forcing TLS to compress email will make mobile email clients more
unwieldy than they already are.

Corby

> -----Original Message-----
> From: ext [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, September 28, 2004 8:44 AM
> To: Wilson Corby (Nokia-ES/Pittsburgh)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [lemonade] Compression: TLS or Application-layer
> 
> > I'm glad you brought this up Eric.  I think this is needed for low
> > bandwidth terminals.  Computational power of terminals is growing
faster
> > than network bandwidth at the current time, so I feel this is a key
> > technology.
> 
> > I think TLS compression is fine, but for consumer level systems
which
> > will not be enabling IMAPS (simply because they don't know what it
is) I
> > think we will need application level compression (like P-IMAPs
GZIP).
> 
> Ignorance is never an excuse. I also fail to see why someone would be
> ignorant
> of one mechanism but aware of another.
> 
> > I agree with Arnt that stream compression is better than individual
> > message compression, but we may be able to define both.
> 
> Just because we can do something doesn't mean that we should. Less is
> almost
> always more, and unless there's a compelling technical advantage to
> performing
> application layer compression (which is why DATA is important), we
have no
> business defining it.
> 				Ned

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 28 Sep 2004 18:19:20 +0200

> setup and difficult to maintain (at least today).

If you use the null cipher, that shouldn't be the case.

> big load on the battery because of the computational power required 
> to decrypt + decompress the stream.  App level compression would 
> improve battery life, but would still require more power than no 
> compression at all.

Right. But you can get the same from TLS by using the null cipher.

...
> unwieldy than they already are.

Do you want to know my neighbour's password? I don't know which 
neighbour it is - just someone whose WLAN AP covers my living room. I 
know he/she uses IMAP, I'll bet I could see both password and lots of 
juicy private mail.

If you insist on "NO TLS!" on wireless devices, then you're forcing your 
customers' email out into the open, where nasties like me can listen, 
and that's going to be painful for your customers. On the other hand, 
if you use TLS, then you can either use the null cipher for better 
battery lifetime, or you can use real crypto.

Arnt

---

From: Mark Crispin <[email-masked]>
Date: Tue, 28 Sep 2004 10:46:37 -0700 (Pacific Daylight Time)

On Tue, 28 Sep 2004, Arnt Gulbrandsen wrote:
> and that's going to be painful for your customers.

I concur with this assessment.

Just about the only unencrypted authenticated service that we have left is 
IMAP with Kerberos authentication, and that may go away soon since hardly 
anyone uses it.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.