Re: [Editorial Errata Reported] RFC7540 (4871)

Cory Benfield <> Wed, 30 November 2016 12:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 304D51294E8 for <>; Wed, 30 Nov 2016 04:53:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.398
X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rv4B8tUsrWrk for <>; Wed, 30 Nov 2016 04:53:05 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF5361294C3 for <>; Wed, 30 Nov 2016 04:53:04 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cC4LE-0005sh-RM for; Wed, 30 Nov 2016 12:50:28 +0000
Resent-Date: Wed, 30 Nov 2016 12:50:28 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cC4L8-0005qs-B8 for; Wed, 30 Nov 2016 12:50:22 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1cC4L1-00010M-MV for; Wed, 30 Nov 2016 12:50:17 +0000
Received: by with SMTP id f82so218751220wmf.1 for <>; Wed, 30 Nov 2016 04:49:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Yz1GhwJTlIoJmBrRlPwVOG83bvDpgEzFN0mahkLq+vc=; b=FPDOrJT008agYy78+mUIcd6zHliSNxUjD4bCkQZdqPMPQ9Dlrxcdg08DA8FytBokwo Yd2PV5OOupDa6Yxhxxv3tRxrPafGlMKVwcSKqnK9XJgvLWxNNKlpoblVwlZsv55V5YCc K078af4W6H4bgWoP7NNpeZg8QoGJI0C+YM0/JsVnoYNFQf6MO2Yn19RcoEhDhesMVduN aarDmUG93I+7XoUJwoGKm0kJTyjcfLwec050NO5cP/VONPW9hjczyEYu3IG5hq5F3J3R oX+RdbiCvOojl7ajiA+MRVMApMZ1u/6L8BfkzS5R92hLHx+cDG9/8GI1eENIPu/P6fGD oQug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Yz1GhwJTlIoJmBrRlPwVOG83bvDpgEzFN0mahkLq+vc=; b=MntZJBTrucX0iWQ1dzALfWoCZoE978adsNo2QpJBOv6POOu2PJ3TSE1XNp+LvBAK1w aMUNhZ+ElIzQU//cZoJ/52DSiu53uP3GugKbBqMNlJR+nyalxHDfI9Fs0goXxYhah2C2 lV1O1P2R91CHkogz/YU4R6C5+nqrSSJk9jXotXC4r6WyKK2+StNmtLmd/PYpgbfINhAz cld1q6F68KB6RX4xWDo8h4mLSBEwu60jHlO7TI+bo36kHwr62L0Y3dBMTwzOvkpsIezg ljzpd4UM+iUvllzQIMcGIlJlzl0no11f7Y5hYv4X6j0jRHElCK6EpV1P4Gi+jAhd8bC9 BfZg==
X-Gm-Message-State: AKaTC03QtmHplegcodjazv2dTWRNrdmebf+F9w8LzFP7/PeOpqRxQiLfvZjyWg4Rn0OOyg==
X-Received: by with SMTP id w6mr29751611wmd.43.1480510188497; Wed, 30 Nov 2016 04:49:48 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id r7sm72931780wjp.43.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Nov 2016 04:49:47 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3257\))
From: Cory Benfield <>
In-Reply-To: <>
Date: Wed, 30 Nov 2016 12:49:46 +0000
Cc: RFC Errata System <>, Mike Belshe <>, Roberto Peon <>, Ben Campbell <>, Alissa Cooper <>, Alexey Melnikov <>, Patrick McManus <>, Mark Nottingham <>, HTTP Working Group <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.3257)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=0.461, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1cC4L1-00010M-MV 25dc2ea234847c5e88beff9ae3f2ba01
Subject: Re: [Editorial Errata Reported] RFC7540 (4871)
Archived-At: <>
X-Mailing-List: <> archive/latest/33041
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

> On 30 Nov 2016, at 09:35, Martin Thomson <> wrote:
> On 30 November 2016 at 19:41, Cory Benfield <> wrote:
>> What happens if both stream A and B are blocked? Should my server endeavour to serve dependent streams in that case?
> I guess so.  You don't want to completely stall out.  Obviously, if A
> and B have a parent with siblings that aren't blocked, then you
> continue there, but if everything is stalled, then I guess it's OK to
> make progress on any stream.
> You could probably devise some sort of scheme where you pick the
> stream using some algorithm or other - maybe based on some best-fit
> criteria.  But I'd say that it doesn't matter at that point: if we
> assume that all streams that aren't blocked depend on blocked streams,
> then none of them will be useful to the other side until those blocked
> streams finish.  All you are doing is avoiding having a completely
> wasted connection.

So presumably the sensible heuristic for this is to do the following logic:

1) Select the streams that depend on stream 0 that are not blocked, completed, or idle, and add them to set A.
2) For each stream dependent on stream 0 that is completed or idle,
    a) Select their children that are not blocked, completed or idle, adjusting their effective weights as detailed in RFC 7540, and add them to set A.
    b) If no streams were selected in part a), but there are streams that are completed or idle streams, repeat step 2) for the children of those streams.
3) If set A is empty, repeat the above but treat streams that are blocked as though they are completed or idle (that is, allow their children to be selected to be served).

I am not sure how many server/intermediary implementations actually implement priority in this manner. It’d be interesting to hear what the others do.