RE: Large Frame Proposal

Jeff said:

> To be clear, my issue is that this change makes determining valid frame

> lengths dependent on the session state which to me seems a step

> backwards both in terms of protocol layering and in terms of the

> achievable decoding throughput based on the simple frame layout.



Jeff also said:

> I fear [changes to SETTINGS_FRAME_SIZE] will happen frequently in

> practice, requiring dynamic changes to the frame encoder/decoder.





We keep repeating that SETTINGS_FRAME_SIZE is a *non-obligatory* message from an endpoint to tell its peer it is *willing* to accept *larger* frames - which is a true statement, an endpoint is never required to send frames larger than 16K.



However, with respect to Jeff's thoughts above, I can see how he might think that dynamic changes to SETTINGS_FRAME_SIZE would require dynamic changes to the frame encoder/decoder.  What happens if the peer reduces the SETTINGS_FRAME_SIZE below 16K, is the endpoint *required* to send *smaller* frames?



The *intent* was that SETTINGS_FRAME_SIZE is *non-obligatory* whether greater or smaller than 16K; a suggestion if you will.  Hence the following requirement in the 'Frame Size' section:



By default, the maximum frame payload size is 2^14 (16,384) octets.

All implementations MUST be configurable to handle frames up to this size correctly.

The default frame payload size is optimized for stream multiplexing and ought to be

used for most cases.



We should probably make this more clear though, particularly in the description of SETTINGS_FRAME_SIZE (&SETTINGS_HEADER_FRAME_SIZE).



This is important because it allows an implementation, like Jeff's, to use a fixed 16K frame size and not worry about dynamic changes to min/max allowed frame lengths.



I suspect many limited-resource embedded implementations would also benefit from a fixed frame size.



(Although hardware acceleration is not part of the charter, I think this property may also be important for HW acceleration as it may be more efficient for HW to deal with a fixed frame size.)



-keith







This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.