Re: [hybi] Payload only compression extension, again

[Takeshi Yoshino <[e-mail]>]

On Wed, Jul 27, 2011 at 00:11, John Tamplin <[e-mail]> wrote:

> On Tue, Jul 26, 2011 at 10:23 AM, Takeshi Yoshino <[e-mail]>wrote:
>
>> Additionally, I'd like to propose one more parameter.
>>
>> - No compression context sharing option
>> -- though I'm claiming that compression context sharing across frames is
>> good, it's sometimes harmful for intermediaries
>> -- for load balancers that dispatches WebSocket frames to different
>> backends, shared compression context means that the load balancer have to
>> perform decompression. it's burden in terms of both memory pressure and CPU
>> power.
>> -- So, I'd add parameter "finish_at_eof" to allow such intermediaries to
>> ask clients not to keep using the same compression context across frames
>>
>
> The problem is that if you don't share compression state across frames,
> then it becomes critical to not try and compress incompressible content.
>  Look at the experiment data I presented in that same thread -- it is very
> easy for frame sizes to go up if you aren't sharing compression state, so I
> think if this option is included we have to decide now how to turn off
> compression on a frame-by-frame basis rather than delaying it for a future
> extension.  In contrast, if compression state is maintained across frames,
> it is still usually a win even on incompressible content because different
> frames have redundancy, and the loss is never bad.
>
>
First, I'd like to make it clear that I intended to make this option one-way
property (i.e. if S included this, no shared-context in C->S direction but
allowed for C<-S direction).

I think it's still ok that clients choose to just compress everything.

With this option, service providers have two choices
1) put this option in extension response to reject shared context while
taking in the possible low efficiency you explained
2) reject compression completely

Inclusion of this parameter implies that the server-side thinks it's more
important to reject shared context than losing compression efficiency.
Looking at your experiment, for some app, there's still some gain from
frame-by-frame compression.

Without this option, they can take only 2).

That's all, I think.


> I would prefer, for the initial version, to simply have load balancers that
> can't maintain compression state to simply refuse compression.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>