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

Re: [Editorial Errata Reported] RFC7540 (4871)

From: Ryan Hamilton <rch@google.com>
Date: Wed, 30 Nov 2016 07:20:26 -0800
Message-ID: <CAJ_4DfQEYQr1OBepx1asM3BwJXHzmnLR089m2KwTtW-F5HPyEg@mail.gmail.com>
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Cc: "tatsuhiro.t@gmail.com" <tatsuhiro.t@gmail.com>, Kazuho Oku <kazuhooku@gmail.com>, Cory Benfield <cory@lukasa.co.uk>, 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>
I completely agree. Priority is all about sending the most important data
first. Flow control is a distinct issue and mixing them together seems
complex and confusing in ways that would limit the effectiveness of
priority.

On Wed, Nov 30, 2016 at 6:54 AM, Stefan Eissing <
stefan.eissing@greenbytes.de> wrote:

> A stream is blocked only by flow-control, as I read it. The errata would
> suggest that the flow control of the parent would effectively rule those of
> its descendants? That does not make much sense to me.
>
> This could easily become very messy. If flow control of dependant nodes
> become entangled with their ancestors, then we basically have nested flow
> control windows? Please. no.
>
> -Stefan
>
> > Am 30.11.2016 um 14:49 schrieb Tatsuhiro Tsujikawa <
> tatsuhiro.t@gmail.com>:
> >
> >
> >
> > On Wed, Nov 30, 2016 at 10:29 PM, Kazuho Oku <kazuhooku@gmail.com>
> wrote:
> > 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.
> >
> >
> > ​I agree with Kazuho.  I think RFC 7540 is written based on the idea
> that dependent stream ca​n receive resource if the streams between it and
> root are all either in closed, idle or blocked.
> >
> > Actually, from nghttp2 commit log, I made a commit which implemented the
> proposed  text.  But we later reverted it, since there is no text in the
> draft at that time to mandate that behaviour.
> >
> > Best regards,
> > Tatsuhiro Tsujikawa
> >
> >
> >
> > >
> > > However, that’s also what the Python Priority implementation does.
> > >
> > > Cory
> > >
> >
> >
> >
> > --
> > Kazuho Oku
> >
> >
>
>
>
Received on Wednesday, 30 November 2016 15:21:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 November 2016 15:21:03 UTC