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

Re: [Editorial Errata Reported] RFC7540 (4871)

From: Kazuho Oku <kazuhooku@gmail.com>
Date: Wed, 30 Nov 2016 22:29:53 +0900
Message-ID: <CANatvzygQViXZy0bxLzm3GK3KmVgT2qgSHio8V+3USDOYWxEGQ@mail.gmail.com>
To: Cory Benfield <cory@lukasa.co.uk>
Cc: Martin Thomson <martin.thomson@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>
2016-11-30 22:05 GMT+09:00 Cory Benfield <cory@lukasa.co.uk>:
>
>
> On 30 Nov 2016, at 13:04, Kazuho Oku <kazuhooku@gmail.com> wrote:
>
> My understanding is that you do not need to distinguish between completed, idle and blocked states.
>
> For a stream under either of the three states, the weight associated to the stream is distributed to the dependents.
>
> That is what nghttp2 does and H2O does (except for the fact that it does not remember closed streams), and I this behavior is what is suggested by the spec.
>
>
> My understanding of what Martin is suggesting is that that isn’t true: blocked streams do not distribute their weight to their dependants.


Thank you for pointing that out.

My understanding is that there is no special casing for blocked
streams. Section 5.3.1 handles all the states we are discussing
equally, quote:

   Inside the dependency tree, a dependent stream SHOULD only be
   allocated resources if either all of the streams that it depends on
   (the chain of parent streams up to 0x0) are closed or it is not
   possible to make progress on them.

I also do not see why it would be beneficial to treat them differently.

>
> However, that’s also what the Python Priority implementation does.
>
> Cory
>



-- 
Kazuho Oku
Received on Wednesday, 30 November 2016 13:30:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 November 2016 13:30:31 UTC