Re: Frame Length Restrictions

One of the requirements for the padding design was to be able to pad the
data by only a single byte. Using a separate padding frame was rejected
because it only allowed padding by a minimum of 8 bytes. Receiving and
trying to pad a full 16K of data with the current spec requires splitting
the frame, which of course requires a minimum of 8 bytes of padding.

We originally dropped the length from 64K to 16K in order to do two things:

1) Increase the likelihood that we force implementations to have to use
continuation frames.
2) Prevent implementations from sending so much data in a single frame that
they cannot respond to incoming re-prioritization information quickly.

Moving the 16K requirement to the HTTP layer still meets those two goals,
and increasing the length frame allows increasing the padding length by a
single byte, even if the full 16K is sent in a frame.


On Wed, Apr 16, 2014 at 6:50 PM, David Krauss <potswa@gmail.com> wrote:

>
> On 2014-04-17, at 8:34 AM, Jeff Pinner <jpinner@twitter.com> wrote:
>
> > With the addition of padding to the framing layer, I believe it is
> preferable to implement the frame length requirement at the HTTP layer to
> allow intermediaries to pad frames without running into frame length
> restrictions.
>
> Is there a particular reason to add back both bits as opposed to just one?
> A 64K frame with 16K of information is quite a lot of padding.
>
> Also, an intermediary can already maximize available padding with a policy
> of preferring to send empty padding frames. There's no limit on the ratio
> of incoming padding to data, so an intermediary which simply preserves
> incoming padding must already be prepared to send anything.
>
> In any case, it sounds like you're solving a specific problem which maybe
> should be mentioned in the RFC. Other than that though, I have no real
> objection... it's a coin-toss issue.
>
>