Re: [hybi] Framing take IV

[Maciej Stachowiak <[e-mail]>]

On Aug 3, 2010, at 5:53 PM, Ian Hickson wrote:

> On Wed, 4 Aug 2010, Greg Wilkins wrote:
>> 
>> I think that we have reasonable consensus on something like:
>> 
>>  +--------------------------------------------------+
>>  | frag(1) |unused(3) | opcode(4) |  Length(16)     |
>>  +--------------------------------------------------+
>>  |                      Data                        |
>>  +--------------------------------------------------+
> 
> Why would we have a fixed length field with fragmentation rather than a 
> variable length field?
> 
> If we can have a variable width length field, do we need to support 
> fragmentation in the first version? I could see an argument for supporting 
> fragmentation in the case of multiplexing, but without that it doesn't 
> seem to actually gain us anything.

I agree. I can't see any benefit to fragmentation over a variable-size length field for an initial version without multiplexing. If the variable-size length field is well-designed, then in the common case where the message size is small it will only cost one extra branch to read the length. In the rare case where the message size is large, a variable-size length is easier to deal with than reassembling fragments, and easier on the sending side too.

I'm not really persuaded we need multiplexing at all until I see data proving the benefits. Useful data would be:

- Average degree of multiplexing we could likely get in real Web applications, based on measured user behavior. I'd like to see this for at least two different Web apps from two different vendors to make sure we are not overtuning to a single vendor's setup.

- Concrete performance benefits of multiplexing over a single TCP connection vs. using multiple connections. I have yet to hear an answer that involves numbers and doesn't sound handwavey.

- Performance cost of implementing multiplexing at the application level compared to doing it at the protocol level (either in terms of more connections resulting and the actual cost of that, or in terms of additional overhead on the client side from using an iframe or shared worker or whatever to share the connection.)

I'm open to trading off simplicity for performance, but only if I see data backing up the performance claims. Every performance project should start with measurement.

Regards,
Maciej