Re: Large Frame Proposal

On 2014–07–09, at 11:42 AM, Roberto Peon <grmocg@gmail.com> wrote:

> Larger framesizes matter only for non-TLS connections.
> That is why I'll hope that most browsers and most servers pick framesizes that are proportional to the TLS record size, and that are relatively small (e.g. 16k or less).

Initial implementations of multiplexers have ample opportunity to shoot themselves in the foot.

The naive way to write a mux is to encode data into the output stream as it arrives from the application threads. Queueing a bunch of short frames adds the same HOL as one big frame. Maybe my intuition about naiveté is wrong, but:

1. An implementation that makes any decision about how much should be enqueued will apply that to the frame size,
2. An implementation that always tries to send as much as possible will incur HOL regardless of the binary frame format,
3. Any workable mux that encounters HOL in the field easily can be fixed by setting an internal limit, likely a hard limit, unless conditions indicate that large send is safe.

We shouldn’t get hung up on what the binary format seems to suggest to programmers. It’s a grammar, and its function is to provide expressive power. Even the simplest languages may express obscenity; censorship is futile. IMHO, frame size limits only feel important now because we’re debating it.

> I'm happy with 16 bits of length. 24 bits of length will slow things down marginally in the common case as we're putting 8 more '0's on the wire for nothing almost all the time.

If we were this nitpicky, the WINDOW_UPDATE frame headers could be halved.

Received on Wednesday, 9 July 2014 04:26:21 UTC