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

Kazuho Oku <> Thu, 09 May 2019 21:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C6A0012008A for <>; Thu, 9 May 2019 14:44:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.607
X-Spam-Status: No, score=-6.607 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_28=1.404, 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 AsAGbFhkr4oa for <>; Thu, 9 May 2019 14:44:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D6301120026 for <>; Thu, 9 May 2019 14:44:22 -0700 (PDT)
Date: Thu, 09 May 2019 14:44:21 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1557438261; bh=fOYPsyS887nVgCOEt80KezKa35Ctk7ccXR2j7SRueJQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=DLDa+MntPSGiFZs7zER5gnbtCUIyPC9H2GZrBhlaSfTwEpLod6qUIPg3J4m7odF1H NltmeIfTw1WVGhkLGQvAK+AqtAGGAClCdP2pvQLGDHNE4jKW5Tnq/YHPLbBrvkJtQ3 ewsrbsy2NBb2CUseWa7hxQUXwxFx1/OPJOf3G8Ck=
From: Kazuho Oku <>
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_5cd49f35defc3_250f3fa7ebacd960376bf"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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 21:44:25 -0000

@pmeenan Thank you for the insights. I think we all agree on what the optimal ordering is.

I think there are three questions:
* How important is it to have serialization _within_ the blocking assets? It is beneficial to deliver blocking JavaScript files one by one rather than doing RR among them, because giving the client to execute _some_ JavaScript_ files earlier helps. However, the question is how much it helps, because I'd assume that in the common case a browser cannot render anything until all the blocking JavaScript files arrive.
* How important is it to have strict serialization between blocking assets vs. images, compared to having 256n:1 distribution where N is the number of blocking assets (i.e. the Firefox approach).
* If we consider either of the above two to be important enough that daisy-chaining is necessary, there'd be chance of having small mis-prioritization windows due to packet loss (the topic of this issue), not only at the very beginning of the connection but every time more than one request is inserted per one RTT. Is that something we need to fix?

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