W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: [Editorial Errata Reported] RFC7540 (4871)

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 1 Dec 2016 10:03:37 +1100
Message-ID: <CABkgnnXXLUfC9q5YSQjRWZOqyPevkVrPT2VKvUAEK7caxQDDng@mail.gmail.com>
To: Cory Benfield <cory@lukasa.co.uk>
Cc: Kazuho Oku <kazuhooku@gmail.com>, RFC Errata System <rfc-editor@rfc-editor.org>, Mike Belshe <mike@belshe.com>, Roberto Peon <fenix@google.com>, Ben Campbell <ben@nostrum.com>, Alissa Cooper <alissa@cooperw.in>, Alexey Melnikov <aamelnikov@fastmail.fm>, Patrick McManus <pmcmanus@mozilla.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On 1 December 2016 at 00:05, Cory Benfield <cory@lukasa.co.uk> wrote:
> My understanding of what Martin is suggesting is that that isn’t true:
> blocked streams do not distribute their weight to their dependants. However,
> that’s also what the Python Priority implementation does.

And this was my error in writing up the errata and my earlier emails.
The spec is clear that there is no functional distinction between
blocked and finished.  The original text is correct.

It's pretty obvious however that it's not clear.  I'd answered on the
basis of first principles, and that was an error on my part.

Mike's algorithm is almost correct, but I would revise it.  Starting
at the top level:

Given a set of dependents of S,
  find all S where not TreeBlocked(S) as S'
  allocate resources to S' proportional to their weights
    for a stream s in S', if StreamBlocked(s), repeat algorithm with
its dependents

Not treating closed as special keeps this simple.  If you were to
treat closed as different to blocked, then you have the issues that
Cory was digging into.

Kazuho points out:
> I also do not see why it would be beneficial to treat them [closed streams] differently.

It's beneficial if you have other streams that are not blocked that
don't have dependencies.

Imagine that you have two HTML files and then images for each as
dependents.  If one HTML file is blocked, then there is potentially
less value in loading the images that depend on it than there is in
making progress on the other HTML file.  Now, that is arguably not
valuable because HTML/image dependencies are sort of loose, but if you
have an application that has absolute dependencies (I can't use this
until you give me that) and other constraints (not enough memory to
buffer), then you can see a way to treating closed and blocked
differently.

Of course, that isn't what the spec says and we don't get to change that :)

BTW, in answer to what people suggested about flow control, that is
only one reason a resource might be blocked.  A resource might be
blocked because the server hasn't finished building it, that might be
IO or processing.
Received on Wednesday, 30 November 2016 23:19:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 November 2016 23:19:18 UTC