Re: Interleaving #481 (was Re: Limiting header block size)

On Tue, Jun 3, 2014 at 2:19 AM, Roland Zink <roland@zinks.de> wrote:

>  On 03.06.2014 11:01, Roberto Peon wrote:
>
> If one does so, then different frames have different max sizes, and are
> parsed differently.
>
> You seem to assume that the length field needs to have a different length,
> although I think this isn't really necessary.
>

Welp, I can tell you that we do see headers, especially for responses that
are > 64k.


>  This would imply that parsing takes more steps than it does today, as it
> would need to examine the frametype, then know the length of the
> length-field, then parse the length field.
>
> The examination of the frametype is necessary today to detect if it is
> header / continuation frame and to handle it differently.
>

Not for the basic framing, though-- that is common across all frames. The
interpretation of the basic framing does require examination of the fields,
but that is a separate (and currently separable) step.
Anything that eliminates the commonality between frames requires conflating
the complexity of interpretation with that of framing.

I'll point out that a non-remuxing proxy can forward frames without
modification given the spec today.


>
>
>  This is more painful, more codepaths and slower in the common
> case/common path.
>
> Even better would be if header frames could be handled like other frames
> and forwarded without much modification.
>

If you're arguing for a 64k limit, then you're saying this will never
happen enough that we'd care, and thus almost all the time header frames
could be forwarded without modification for a 1:1 proxy.
If you're arguing that 64k is too little, then you either want every
frame's size to be increased, which would likely (as experience has shown)
increase muxing latency, or you want to string sequences of frames together
as is done with the spec today, or you have different sizes for each frame,
which breaks the ability to do basic parsing or dumb inspection.

-=R



>
>
>
> -=R
>
>
> On Tue, Jun 3, 2014 at 1:48 AM, Roland Zink <roland@zinks.de> wrote:
>
>> The simple abstraction that headers + continuation can be treated as a
>> single unit is similar to a single frame. Wouldn't it be a cleaner
>> abstraction to merge this into one frame?
>>
>> Regards,
>> Roland
>>
>>
>>
>> On 03.06.2014 01:02, Martin Thomson wrote:
>>
>>> On 22 May 2014 06:13, Michael Sweet <msweet@apple.com> wrote:
>>>
>>>> https://github.com/http2/http2-spec/issues/481
>>>>
>>> Quoting:
>>>
>>>> Currently the HTTP2 draft requires that HEADER frames be contiguous.
>>>> Since a header block can be arbitrarily large, this presents both an
>>>> obvious DoS vector and a practical issue with streaming performance and
>>>> preservation of the priority scheme that HTTP/2 provides.
>>>>
>>>> A simple solution is to allow intervening DATA frames on other,
>>>> established streams. That will allow high-priority data through without
>>>> major interruptions.
>>>>
>>> As a DoS vector, the only parties being denied service are the parties
>>> engaging in the HTTP/2 connection, which is not an issue.  Those
>>> parties have far better means of denying each other service than this.
>>>
>>> The impact on multiplexing is largely congruent with the above.  The
>>> best response here is "don't do that" with respect to large header
>>> blocks.  In the worst cases (those in the tail of Richard's stats),
>>> this is ~64k, which will have those parties adversely affected.
>>>
>>> The only place this is an actual problem is where messages are merged
>>> from multiple clients (or origin servers) onto a single connection by
>>> an intermediary.  In those cases, the intermediary is basically
>>> responsible.
>>>
>>> An intermediary can apply policy to prevent this from happening.  It
>>> seems like many already do this, by setting a limit (8k being fairly
>>> common).  Other options include putting bad actors into TIME_WAIT,
>>> putting all bad actors into a separate low bitrate connection.
>>>
>>> The main reason I'm against this change is that it prevents the sort
>>> of clean abstraction that we currently have, which states that HEADERS
>>> + *CONTINUATION or PUSH_PROMISE + *CONTINUATION can be treated as a
>>> single contiguous unit.  An implementation that fails to apply that
>>> abstraction ends up with the state machine Greg shared with us in #484
>>> (which is incomplete, BTW).
>>>
>>>
>>
>>
>
>