Re: [hybi] Frame size

[Greg Wilkins <[e-mail]>]

Scott Ferguson wrote:
> Greg Wilkins wrote:
>> In fact, I would argue for a 16k max frame size with 2
>> bits given over to help with partitioning and aggregation,
>> but with no requirement that an endpoint can handle
>> aggregation and partitioning (unless they indicate they
>> can in the handshake).
>>   
> 16k is fine, but why are two bits needed instead of one? 

1 bit is fine for pure fragmentation.

I suggested 2 bits because of previous discussions on
the list about a bit indicating if an intermediary
can buffer a frame or not.  This gives the ability
to have streaming frames plus other frame types
(see BWTP post for an example of using the 2 bits).

However we could get the streaming by just having
a single bit for fragmentation and the spec can say
that all intermediaries must forward all frames immediately.

So I think for simplicity's sake, a 16k frame size
with 1 bit for fragmentation and 1 bit reserved for future
use would work fine.  (or 32k and no reserved bit).


> I'd think basic chunking would be a requirement like HTTP/1.1, not a
> negotiated capability, to support messages over 16k and also to the
> reduce the round trip latency as discussed in the other thread.

I agree.

If we consider the complexities of error handling for unlimited
sized frames - then I think the simpler solution is to have
unlimited sized messages that are sent in 1 or more limited
sized frames.

Perhaps that reserved bit can then be used for control/error
frames ie if the unlimited message is too large a control/error
frame can be sent to say enough already!

cheers