Re: HTTP/2 GREASE, Results, and Implications

Hi Tom,

Thank you for raising this issue.  I agree with the requirements that you
outline with respect to the NEW_PRIORITY frame.

Just a comment that in case it is not possible to resolve the issue in a
way that's favorable to the priority use case (for example, if the
timeframe for updating all deployments in not acceptable for the desired
timeframe of launching priorities), then another option would be to send
priority-related frames on stream 0, and encode the stream ID they refer to
within the frame payload.  Sure that's a waste of four bytes per frame, but
at least it should work (as long as implementations are correctly
discarding unknown frames on stream 0).

Bence

On Fri, Nov 15, 2019 at 10:10 AM Tom Bergan <tombergan@chromium.org> wrote:

> I would like to revisit the ambiguity that Willy pointed out in this
> thread. On the one hand, we have this statement, which appears in Sections
> 4.1 and 5.5:
>
> 1. Implementations MUST discard frames that have unknown or unsupported
> types.
>
> On the other hand, we have statements like the following, which appear in
> Section 5.1:
>
> 2a. idle: Receiving any frame other than HEADERS or PRIORITY on a stream
> in this state MUST be treated as a connection error.
>
> 2b. half-closed (remote): If an endpoint receives additional frames, other
> than WINDOW_UPDATE, PRIORITY, or RST_STREAM, for a stream that is in this
> state, it MUST respond with a stream error
>
> If this ambiguity is resolved in favor of Section 5.1, then it becomes
> difficult or impossible to define a new priority scheme in an HTTP/2
> extension. In particular:
>
> - It might be desirable to send a NEW_PRIORITY frame before HEADERS, as a
> replacement for priority information that is built into HEADERS. This
> conflicts with (2a).
>
> - It might be desirable to send a NEW_PRIORITY frame after END_STREAM, so
> the client can reprioritize a lengthy response. This conflicts with (2b).
>
> For this reason, I propose that this ambiguity should be resolved in favor
> of Section 5.5. We should release an errata which clarifies that the rules
> in Section 5.1 do not apply to frames of unknown type. If an extension
> defines a new frame type, it must explicitly enumerate the states in which
> that frame can be sent and received. Willy also raised a concern about new
> frame types that include END_STREAM. I think this is covered by Section
> 5.5, which says "Extensions that could change the semantics of existing
> protocol components MUST be negotiated before being used." If a new frame
> type can end the stream, this adds an edge to the state diagram in Section
> 5.1, therefore, support for the new frame type must be negotiated before it
> can be used.
>
> Thoughts?
>
> On Wed, Nov 6, 2019 at 12:27 PM Willy Tarreau <w@1wt.eu> wrote:
>
>> Hi Bence,
>>
>> On Wed, Nov 06, 2019 at 03:03:18PM -0500, Bence Béky wrote:
>> > Hi,
>> >
>> > I added two simple command line flags to Chrome to trigger sending
>> greased
>> > HTTP/2 elements, and they are available since version 80.0.3960.0 (not
>> on
>> > Linux quite yet).
>>
>> OK, thanks for letting us know.
>>
>> > --http2-grease-settings adds one settings parameter with a reserved
>> > identifier and random value to every SETTINGS frame sent (one per HTTP/2
>> > connection).
>> >
>> > --http2-grease-frame-type sends one frame of reserved type and random
>> short
>> > payload after every SETTINGS and HEADERS frame, including HEADERS frames
>> > with END_STREAM flag set.  This is what caused problems apparently with
>> > Cloudflare and Akamai.
>>
>> And haproxy, given that this violates the rule of no frame type other than
>> the few allowed one in half-closed remote state. The problem with allowing
>> new frame types during forbidden states is that we could make it way
>> harder to implement these new frame types later without risking to see
>> them behave differently depending on implementations. I suspect that if
>> we want to go down that route we'll need to either reserve certain frame
>> types as carrying no payload for streams and others as possibly having
>> some :-/ In addition, frame flags are defined per-frame, eventhough we
>> all know they are the same. But new frames exhibiting an END_HEADERS
>> flag or an END_STREAM flag cannot be completely ignored. Frames
>> designating an idle stream ID which are not HEADERS frame will also
>> possibly create a stream or not and cause issues. I think that at the
>> moment the only way we have to continue to ignore frames is :
>>
>>   - ignore the unknown ones on stream 0
>>   - ignore the unknown ones on non-idle, non-half-closed(remote) streams
>>   - respect existing rules for existing states (i.e. reject what doesn't
>>     match certain types for idle, half-closed, reserved.
>>   - and likely define how to deal with known flags in the remaining
>>     cases.
>>
>> Just my two cents.
>>
>> Cheers,
>> Willy
>>
>>