Re: Stream limits draft posted

On Wed, Nov 08, 2023 at 10:00:07AM +0100, Kazuho Oku wrote:
> 2023年11月6日(月) 16:04 Martin Thomson <mt@lowentropy.net>:
> 
> >
> > https://datatracker.ietf.org/doc/html/draft-thomson-httpbis-h2-stream-limits-00
> >
> > We've talked about this, but Lucas and I have scrubbed it a little.
> >
> > This is not a proposal that comes with a statement of "this fixes the
> > problem", so the discussion we have about this will be very important.  But
> > if some servers benefit from doing things this way and clients are willing
> > to implement, then it might be worth doing.
> >
> 
> Thank you for publishing the draft.
> 
> If the problem can be addressed by changing the specification, then that
> would be great!
> 
> Regarding how, I have two comments to the current state of the draft.
> 
> One is that the current approach does not provide a hard limit on the
> number of streams that can be opened; this is because until SETTINGS are
> exchanged, clients can open any number of streams.

While this is true, the client should also be prepared to handle if
streams are refused.  Of course, that is all good in theory.  In
practice, there are _some_ application developers who use libraries to
implement HTTP/2, and _sometimes_ neither the application developer or
the HTTP/2 library take steps to recover from refused streams.

> As said previously [1],
> IMO it would make sense to state that endpoints implementing this extension
> MUST NOT open a hard-coded number of streams until it negotiates the use of
> the new scheme.

There seems to be consensus that the limit of INT32_MAX is way too high.

I think the RFC "recommendation" of 100 is also too high, but 0 would be
too low.  This extension provides an opportunity to specify a hard-coded
starting value rather than a "recommendation".  For the benefit of
resource-constrained systems, as well as to institute a more sane limit
on initial requests that can be abused in DoS attacks, I would propose
that if a client sends MAX_STREAMS to indicate support for MAX_STREAMS,
that the client should also presume a value of 8 or 10 for
SETTINGS_MAX_CONCURRENT_STREAMS until SETTINGS is received from the
server.  (If the server sent MAX_STREAMS following SETTINGS, then
MAX_STREAMS should be used.  If MAX_STREAMS was not sent by the server,
then the client could try its prior behavior, which might assume 100 for
SETTINGS_MAX_CONCURRENT_STREAMS.)

lighttpd sets SETTINGS_MAX_CONCURRENT_STREAMS 8, but tries to be more
accommodating to an initial burst of streams prior to SETTINGS ackn.

F5 sets SETTINGS_MAX_CONCURRENT_STREAMS 10 according to
https://my.f5.com/manage/s/article/K000137106,
"The default value for streams per connection is set to 10 because F5 had anticipated this type of flaw in the HTTP/2 protocol."

For scenarios sending a huge number of initial requests, if popular
client browsers were to handle queueing of requests for MAX_STREAMS
(or SETTINGS_MAX_CONCURRENT_STREAMS 8), that would go a long way
towards seamlessly supporting javascript developers who might not retry
refused requests.

For mass revalidation, the cache groups proposal sounds promising.

> If we could use a new ALPN to indicate the use of this extension, this
> problem goes away.
[...]
> Servers can simply stop supporting vanilla H2, only supporting access using
> the new safe variant and HTTP/1.1.

I disagree.  ALPN h2 will need to be supported by generic servers for the
long forseeable future.  Even if popular clients are updated, there will
still be many deployments that do not update for many years, and many
distros "stable" releases -- where "stable" is unfortunately all too
frequently equivalent to almost "unmaintained" -- which do not update.

Cheers, Glenn

Received on Wednesday, 8 November 2023 13:05:10 UTC