Re: Large Frame Proposal

On 11/07/2014 12:32 a.m., Tatsuhiro Tsujikawa wrote:
> On Thu, Jul 10, 2014 at 8:00 PM, <K.Morgan@iaea.org> wrote:
> 
>> Hi Yoav-
>>
>> On Thursday,10 July 2014 12:47, ynir.ietf@gmail.com wrote:
>>> Is that for every frame, or just when a large frame size has been
>> advertised?
>>> I guess the former, but then we're increasing every frame by 2 bytes for
>> the
>>> same of those 0.02% No?
>>
>> Our proposal (Greg et al) already had the extra 2 bytes from the
>> beginning, see the first e-mail (from Greg) in this thread [1].  I simply
>> extended the reserved bits from 1 to 8 to appease concerns by Roberto and
>> others that too many bits is too big of a foot gun, but simultaneously
>> allows future revs of the protocol to *easily* extend the frame length
>> field if necessary.
>>
>>
> If reserved bits are for future use for larger frame size, why not reserve
> 16 bits for now?
> It makes a foot gun even less likely​.  I heard that many said that 16 bits
> length is enough for today.
> 
> With 16 bits available (2 bits extra from h2-13's 14 bits), we can say good
> bye to CONTINUATION.  This solves #549 and #550 (and possibly #551 for <
> 64KB, but I think it is enough).  Extra 16 reserved bits is a possible
> solution of #553.
> 
> Best regards,
> Tatsuhiro Tsujikawa
> 

So in effect, adding 16 bits of reserved space before the length. THen
defining that when the SETTINGS_HEADER_FRAME_SIZE extension setting is
received is un-reserves 8 or 16 of those bits and the become a longer
length value.

Lets call a spade a spade:
  24/31-bit length field with a default maximum size of 16KB.

Amos

Received on Thursday, 10 July 2014 12:52:32 UTC