Re: [hybi] preliminary WebSockets compression experiments

[Mike Belshe <[e-mail]>]

On Tue, Apr 27, 2010 at 6:37 AM, Jamie Lokier <[e-mail]> wrote:

> Mike Belshe wrote:
>  And the best answer is to have the protocol help avoid it.
> >     You can do so by encrypting everything to avoid tampering, or you can
> >    avoid it by mandating compression.
>
> It's not necessarily "best".
>
> First, if you encrypt everything end to end, that will prevent
> intermediaries from applying joint compression to multiple streams.
> That is most relevant to opportunistic multiplexing, but it isn't the
> only way.
>
> The results which started this thread strongly imply that joint
> compression of a stream of small objects is sometimes far better than
> individual compression of them - enough to tip the balance in favour
> of compression versus not, in some cases.
>
> Second, end to end encryption rules out some devices from using the
> protocol at all - they don't have enough processing capacity and/or
> memory to do it.
>

I don't believe this to be true.


>
> Third, same applies to mandatory compression, if it is one of the
> compression types which needs a lot of processing and/or memory.
>

I don't believe this to be true.  Processing power grows very fast in all
hardware.  You're going to have a quadcore on your mobile phone in 5 years.


>
> Fourth, we know that many client locations block many different kinds
> of outgoing traffic, and some of them block anything they don't
> understand.  That no doubt includes all encrypted traffic from some of
> them.  It should not be mandatory to encrypt, for that reason.
>

This is wrong; encryption protects the user and is valuable.  It will be
coming whether you like it or not.



>
> Fifthly, forcing implementations to use a compression scheme which was
> good in the year 2000 (deflate), is looking a bit dated now for
> compression performance (bzip2, lzma are better for many things), and
> is too compute intensive for on the fly encryption on slower or
> heavily loaded or power-sensitive devices (lzo family are better for
> that)... projecting ahead to 2015, 2020, the "mandatory" part of the
> spec would probably get ignored or worked around by many implementations.
>

Fine - I never made a claim that a specific algorithm must be mandated.


>
> Sixthly, we're assuming proxy-caches play no role in these protocols.
> With WebSocket itself, that's true, but with protocols like SPDY that
> might be layered over it, it is likely (imho) that a role will be
> found for proxy-caches.  End-to-end encryption is not compatible with
> that.
>

You're ignoring the problems caused by proxies.  I won't go into them again.
 But the hazards are so large that, for the last 10 years, basic protocol
changes have been unimplementable due to proxies.  New protocols should not
ignore this.

Mike


>
> -- Jamie
>