Re: [quicwg/base-drafts] PRIORITY frame on control stream referencing unopened request stream (#2502)

Patrick Meenan <> Thu, 09 May 2019 22:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91277120128 for <>; Thu, 9 May 2019 15:04:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.393
X-Spam-Status: No, score=-6.393 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GZW3txCSbeJR for <>; Thu, 9 May 2019 15:04:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D288E12008A for <>; Thu, 9 May 2019 15:04:53 -0700 (PDT)
Date: Thu, 09 May 2019 15:04:52 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1557439492; bh=kenKs38OTD+6Yfw1u9dZiAy3aToJQ5Dkhuj7lgSASRs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=vYE+06i47pcYZ7di//PmRiGl5XXiH5GmF/Kwcf1SMMlQHk4h/dbRkDqi3jevGm2oD RkvI2ADxddIfbAo0z088j0UDnXWc9zKeLdeg43eoa/M7MtaMTP/ZlaGMhIKygiYV2h zQQ+GHbCaWloGi29jZA+TjdZu5HyOFZtCl75yCfQ=
From: Patrick Meenan <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2502/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] PRIORITY frame on control stream referencing unopened request stream (#2502)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cd4a404d8216_6bb23fd9994cd9681351f2"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: pmeenan
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 May 2019 22:04:56 -0000

Serialization within the blocking assets can help quite a bit because the download, parse and eval can be pipelined. If they download in parallel then all of the execution gets batched up after they finished downloading.

"Strict" serialization between blocking and images may not be necessary as long as the ratios are high enough that it is "effectively" serialized. If I recall, the Firefox tree weights the split between groups as 200:100 (for non leader/follower) which isn't enough to pull off effective serialization but it can certainly be done with something like the Firefox tree. If each group could be tagged as round-robin vs serialized it could eliminate the need to build a deeper tree.

Small windows are fine, it's all best-effort anyway otherwise we get HOL blocking. That said, inserting 1 resource per RTT seems like it would be a problem if the RTT's are all serialized. If the cost to boost priority was 1 RTT per resource but they could all be done in parallel it would be fine. Something like a 200-resource page with a 100ms RTT is 20 seconds to prioritize all of them.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: