Re: H2 HEADERS and flow control

In message <CAH_y2NHQ6EfWt3ooaF_ovjOoH6ghLFCoMp00ixvaMuvJQSBsFw@mail.gmail.com>
, Greg Wilkins writes:
>--089e01419ffaa7ff4b04fd543893
>
>On 4 July 2014 03:54, Nicholas Hurley <hurley@todesschaf.org> wrote:
>
>> I'm not convinced this is the case, though. If you have some bad (or at
>> least selfish) actor that is already shoving data into headers to avoid
>> flow control, then I would imagine this situation would make them want to
>> shove even MORE data into headers, since it's still not flow-controlled,
>> but harms their data. What's the "best" way around that for one of those
>> actors? Put it ALL in headers. Perhaps I'm just more pessimistic than you
>> are, though :)
>
>
>I've thought about these type of malevolent actors also.   I think that
>there is nothing in the current draft that prevents them from acting in
>this way in any case.   If they want to write custom clients to write
>IPoverHTTPv2Headers, they can and probably will.

Forcing them to put it all into one HEADERS frame would be mildly
discouraging because they might bang against the default 16KB
limit.

If they feel that large HEADERS frames hurt multiplexing, that would
discourage them too.

>But my thought bubble is aimed more at naive actors, who are using normal
>clients, but who's cookies are getting large or are including big kerberos
>keys etc. etc.      Just because their headers creep up to 32KB say, should
>not mean that they get 50% more fair share than a stream that has no
>headers.

But does the mitigation of this issue belong on the request side of
things ?  Isn't that something the server should rule by scheduling
the responses ?

How often do we have the congestion on the request side of things
under non-DoS conditions in the first place ?

I think flow-control should work this way:

A) Make all frames subject to the connection window so that any
   node can balance multiple competing connections against each other.

B) Make all but the first frame (ie: HEADERS or PUSH_PROMISE) on a
   stream subject to stream windows, to balance different streams
   against each other.

C) Cap the size of the first frame on streams with SETTINGS.
   All implementations must be configurable to a value of 16383
   and values less than 256 are illegal.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Friday, 4 July 2014 08:11:14 UTC