Subject: [hybi] Allow client to control that the server may or may not use c2s_max_window_bits extension parameter

From: Takeshi Yoshino <[email-masked]>
Date: Mon, 15 Oct 2012 18:07:22 +0900

Joakim pointed out that configuring LZ77 window size is not feasible on
Java in this thread
http://www.ietf.org/mail-archive/web/hybi/current/msg09863.html. Sorry that
this was not well considered well in the spec.

My temporary proposal in this thread was:
1) allow client to control if the server may or may not use
c2s_max_window_bits
2) allow server to reject s2c_max_window_bits

But now I think 2) is not the best solution. Client may want to give up use
of compression than accepting full-sized window. If 2) is taken, such a
client needs to reestablish WebSocket connection without
permessage-compress extension.

Since the method parameter of permessage-compress extension can list
multiple method requests, the client can choose to send
  method="deflate; s2c_max_window_bits=8, deflate"
to tell the server that it prefers bits of 8 but it's fine with using 13, or
  method="deflate; s2c_max_window_bits=8"
to tell the server that it really wants to use bits of 8 or fallback to
no-compression mode if the server cannot.

I'd like to suggest that we make only change (1.

Thanks
Takeshi

---

From: Simone Bordet <[email-masked]>
Date: Mon, 15 Oct 2012 12:30:49 +0200

Hi,

On Mon, Oct 15, 2012 at 11:07 AM, Takeshi Yoshino <[email-masked]> wrote:
> Joakim pointed out that configuring LZ77 window size is not feasible on Java
> in this thread
> client needs to reestablish WebSocket connection without permessage-compress
> extension.
>

May I ask what is the use case for supporting window sizes different from 32k ?

I ask because I think it complicates the specification quite a bit
(number of test cases, checks whether the value is between 8 and 15,
etc.), small windows have proved to lead to bad compression, and to my
knowledge 32k is the window size that I have seen used everywhere (but
then again, I am a server guy).

Takeshi, do you have empirical data that shows that usages of window
sizes different from 32k is widespread and hence needs to be supported
?

Given the current size and trend for memory of embedded devices, I am
dubious windows less than 32k will ever be used, but I'll be happy to
be corrected.

Also, it is my understanding that the compressor needs eventually to
specify the window size to the library before compressing, but the
decompressor will just work with any window size.
If that holds true, what is the reason to tell the remote endpoint
what window is being used ?

Thanks !

Simon
-- 
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

---

From: "Arman Djusupov" <[email-masked]>
Date: Mon, 15 Oct 2012 14:14:57 +0300

Reposting to the proper thread.

The benefit of using an asymmetric configuration with the DEFLATE algorithm
is very small. It would be OK if there is no negotiation of the window size.

In general, providing the ability to configure the window size is of limited
benefit while it increases complexity, so another option is to entirely
remove the sliding window size parameters and use a default value in every
case.

With best regards,

Arman

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Takeshi Yoshino
Sent: Monday, October 15, 2012 12:07 PM
To: [email-masked]
Subject: [hybi] Allow client to control that the server may or may not use
c2s_max_window_bits extension parameter

Thanks
Takeshi

---

From: "Arman Djusupov" <[email-masked]>
Date: Mon, 15 Oct 2012 14:13:31 +0300

The decompressor must use a window size that is larger or equal to the
compressor's window size. If the decompressor's window size is smaller than
the one used by the compressor, then the decompressor cannot resolve
references that are outside its window.

With best regards,
Arman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Simone Bordet
Sent: Monday, October 15, 2012 1:31 PM
To: Takeshi Yoshino
Cc: [email-masked]
Subject: Re: [hybi] Allow client to control that the server may or may not
use c2s_max_window_bits extension parameter

Also, it is my understanding that the compressor needs eventually to specify
the window size to the library before compressing, but the decompressor will
just work with any window size.
If that holds true, what is the reason to tell the remote endpoint what
window is being used ?

Thanks !

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are, to deliver
bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz
_______________________________________________
hybi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/hybi

---

From: Simone Bordet <[email-masked]>
Date: Mon, 15 Oct 2012 16:36:30 +0200

Hi,

> remove the sliding window size parameters and use a default value in every

I'm +1 for removing the sliding window size parameters and defaulting to 32k.

Devices that need to run with incredibly small memory requirements may
write their own extension, either with a different algorithm, or with
a smaller window size that is implicitly agreed by both client and
server (e.g. calling the extension "deflate-8" for 8 bits window
size).

I'm guessing that if the device can run a browser, then a 32k window is ok.
Is there evidence from mobile browser vendors that this is not the case ?

Thanks !

Simon

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 16 Oct 2012 01:25:34 +0900

Hi Simone,

> sizes different from 32k is widespread and hence needs to be supported
I thought that when we use lots of long-lived WebSocket sessions and each
of them uses the same compression context for all messages, memory pressure
of compression context (40k * number of connections when bits=15 all the
time even if they're idle for most of time, while HTTP requires 40k *
number of response messages received simultaneously on the server) will be
problematic for servers handling hundreds of connections. That's the reason
I've added this option to allow the server side to ask the client side to
use smaller window size. s2c_max_window_size was added as a bonus
considering embedded systems.

This is the post where I proposed addition of these parameters. The John's
post referred in this post suggested that window bits of 10-11 is
recommended and sufficient.
http://www.ietf.org/mail-archive/web/hybi/current/msg07935.html

But as shown on this post, the difference is not so big. zlib decompressor
needs 10k for bits=8, 10k for bits=10 and 40k for bits=15. Just ~4 times.
http://www.ietf.org/mail-archive/web/hybi/current/msg07980.html

Comments are welcome. Please let me know your thoughts on trade-off between
flexibility of window size and complexity of negotiation.

> decompressor will just work with any window size.

These options are to allow an endpoint to reduce the size of memory to be
allocated for its decompressor by telling the other side the window size to
use for its decompressor in advance.

32kB decompressor works for any data. 256B decompressor works only for data
compressed using 256B window as Arman already answered.

---

From: Simone Bordet <[email-masked]>
Date: Mon, 15 Oct 2012 20:39:05 +0200

Hi,

On Mon, Oct 15, 2012 at 6:25 PM, Takeshi Yoshino <[email-masked]> wrote:
> I thought that when we use lots of long-lived WebSocket sessions and each of
> them uses the same compression context for all messages, memory pressure of
> compression context (40k * number of connections when bits=15 all the time
> even if they're idle for most of time, while HTTP requires 40k * number of
> response messages received simultaneously on the server) will be problematic
> for servers handling hundreds of connections. That's the reason I've added
> this option to allow the server side to ask the client side to use smaller
> window size.

That is true if all connections are compressed, which may not be the case.
Furthermore, browsers/clients will eventually implement MUX, reducing
the number of connections needed towards a single server.
I guess that's the reason why this was never a much discussed problem
in SPDY, although attention has been paid to it.

> s2c_max_window_size was added as a bonus considering embedded
> systems.
>

There are 4 parameters for the deflate method, which makes 16 test
cases and 16 branches in the implementations to take care of the
various cases (valid and errors).
I already imagine implementations taking shortcuts to avoid to cope
with all cases, or just because they cannot easily set those
parameters, e.g. for lack of library support.

FTR, window size and mem_level are not settable in Java (defaulting to
15 bits and 8, respectively) without resorting to external, native
libraries.
The JEE space is standardizing the server-side Java API for WebSocket,
so eventually there will be JEE web applications using WebSocket like
now there are Servlets (i.e. a lot).

I asked for data evidence because while I understand the need for
flexibility, if only 0.01% of applications using deflate use a window
size different from 32k, then perhaps it's not worth, and as I said,
there is always the possibility to write a custom extension for e.g.
embedded devices.

Thanks !

Simon

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 16 Oct 2012 11:31:03 +0900

Hi,

> That is true if all connections are compressed, which may not be the case.

Right. The server can choose which connection to use compression. The ratio
of compression enabled logical channel per web app might be small.

> the number of connections needed towards a single server.

Even with multiplexing, each logical channel spends memory for its
compression context. Because of concern with CRIME attack, I've added a
text to discourage use of compression to output of multiplexing.

It's true that multiplexing reduces the total amount of memory (e.g. kernel
resource for TCP) per logical connection (= number of WebSocket instances)
and it might make memory consumption for compression context affordable.

> parameters, e.g. for lack of library support.
After taking in the change I've proposed in this thread in response to
Joakim, s2c_max_window_size and c2s_max_window_size become  optional
feature.

- Client implementors can choose not to send c2s_max_window_size to skip
implementing c2s_max_window_size.
- Server implementors can choose not to accept request w/
s2c_max_window_size to skip implementing it.

As a result, these specs might be ignored by most of implementors as you
said, but we can keep these options available for people who want them.

So, the problem is complexity of the spec document. I'll try to make the
spec less complicated and these options look optional clearly. If it turned
out to be hard to do so, I'll just remove these texts. Please give me 1 day.

Thanks

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 16 Oct 2012 12:46:51 +0100

> Is there evidence from mobile browser vendors that this is not the case ?

At the small end:

I'm increasingly seeing WebSocket be used as a de facto "simple
message" replacement for TCP in some small embedded environments, that
don't even have enough memory to run a Linux kernel, let alone a
browser.

   http://www.google.com/q=mbed+websocket
   http://www.google.com/q=arduino+websocket
   http://www.google.com/q=embedded+websocket

Probably because it puts Javascript and C, and browser and bare-metal
environment, on an equal footing with the same servers; and because
it's standardised.

I have no idea if the 32k window is an issue, when those things have a
few WebSocket connewctions per client going on.  Just pointing out, it
is used on small devices not just browsers.

On the large end:

There is some value in limiting the memory use of mostly-idle and
active WebSockets on the server, along with TCP tuning (mainly window
size and queuing limits), in order to boost the number of connections
per server, to e.g. the order of 1 million connections per server.

Unlike with HTTP it's not always acceptable to drop/churn connections
under load, and the payloads can be very small.

Again I have no idea if the compression extension's 32k window is an
issue for this.  However, it's larger than TCP memory and other
connection state when those are tuned for size (except TLS which is a
reason to use something else in this situation)

-- Jamie

---

From: "Arman Djusupov" <[email-masked]>
Date: Tue, 16 Oct 2012 16:10:55 +0300

I would like to note that real memory requirements are larger than just the
window size, which is only one consideration. Except of the window size,
ZLib also allocates a considerable amount of additional memory for various
tables, such as the table of hashes which does not depend on the wsize
setting but on the number of hash_bits. In the default configuration the
latter has a size of about 128KB. If we add the size of the output buffer +
some other small tables required by ZStream we can easily climb to 200KB for
compression + some amount of memory required for decompression. So the total
cost per connection would be around 260 KB, while Takeshi's proposed
negotiation would allow us to save +/- 32KB. The amount of memory used by
the hashes can be lowered by reducing the hash bits. However I doubt that
any implementation would go that far in trying to reduce the amount of
memory used, plus doing so can result in very poor compression ratios for
the same processing time taken.

So if the server is to handle a million connections I'm not sure that
DEFLATE would be more affordable than TLS.

With best regards,
Arman

-----Original Message-----
From: Jamie Lokier [mailto:[email-masked]] 
Sent: Tuesday, October 16, 2012 2:47 PM
To: Simone Bordet
Cc: Arman Djusupov; [email-masked]
Subject: Re: [hybi] Allow client to control that the server may or may not

At the small end:

On the large end:

-- Jamie