Re: [quicwg/base-drafts] HTTP/3 with strict priorities (#2700)

Kazuho Oku <> Thu, 16 May 2019 04:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4376A1200DE for <>; Wed, 15 May 2019 21:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Status: No, score=-8.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 sMqk3zYAKy9L for <>; Wed, 15 May 2019 21:51:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 37B041200A2 for <>; Wed, 15 May 2019 21:51:32 -0700 (PDT)
Date: Wed, 15 May 2019 21:51:31 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1557982291; bh=BYeqh85PEKwXjVVvH6GYLsD0Bui/gYP8nh7pms9nwQc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=iO3w6QhFE6X+nTXDsKnIqBTXICCQL0zYgmvY0KjpcJSBouND3l8zIBhg8AN+eBrkm u9BpsMxA/sqpRJXranQacHGhA7CYv+u3zYohs7pMXTj2JoNEbhlWpQfthaUgL/uWyR uSk7cDBEn7P/0gUniSDwBze5Z1osZgzEpuOYWx1A=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2700/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] HTTP/3 with strict priorities (#2700)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cdcec534819e_5a2f3f98a06cd9644915e"; 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, 16 May 2019 04:51:34 -0000

kazuho commented on this pull request.

 Requests may override the default initial values by including a PRIORITY frame
 (see {{frame-priority}}) at the beginning of the stream. These priorities
 can be updated by sending a PRIORITY frame on the control stream.
+Higher priority elements have all available data sent before elements of lower
+priority.  When multiple elements have the same priority, if a weight is
+specified, elements with weights are interleaved.  If a weight is not
+specified, then elements are delivered sequentially and all available data
+from one element is sent before any data from the next.  If a given priority
+level has some elements with weights and some without, the two groups share
+the available bandwidth equally.

Would it make sense to change the requirement of the last sentence to something like: "If a given priority level has some elements with weights and some without, those without weights are sent before any of those with weights"?

I suggest this because it would be a simplification. Current text requiring the bandwidth to be evenly split between the two groups essentially suggests implementations to create one more WRR instance - I prefer avoiding that.

I think such a change is fine because I do not think most of the client would use the prioritization scheme in such a way, and because clients that indeed want in fact to split the bandwidth can use placeholders to accommodate that.

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