Re: [quicwg/base-drafts] Orphan Placeholder (#2690)

Kazuho Oku <> Fri, 17 May 2019 01:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DBB66120334 for <>; Thu, 16 May 2019 18:17:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.606
X-Spam-Status: No, score=-6.606 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, 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 JWuslc3ayGFG for <>; Thu, 16 May 2019 18:17:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4A69B120333 for <>; Thu, 16 May 2019 18:17:03 -0700 (PDT)
Date: Thu, 16 May 2019 18:17:01 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1558055821; bh=9e+0AgalMJcRVaRQQJutrQW/kndWxgoUIAXoZS0jdWY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Qw+uzp+YkMKRYHQS9hNW0vGe+7EUXa7696pZBPrOctUn+NFlcVdo8ILMw4dEMEBhQ XEgKeLlh5l869o+PaGt+wqb2rL8HRi11zL38Tt687Nr9Qa+9P0f326DfNYhQq+3xmL yCSq0QYYN0k7K3JV7VnRfaynKUto9ApzwU9vAHz0=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2690/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Orphan Placeholder (#2690)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cde0b8da3cc2_6a3f3fd581acd960242113"; 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: Fri, 17 May 2019 01:17:05 -0000

> I want to come back to weight=0 for a moment, because it would allow use to make a node not receive any bandwidth until all its children are finished.

I believe you mean "until all its siblings are finished."

> Imo weights between 0 and 255 works as well as between 1 and 256. You might say the weight=0 is a 'special case' but I would disagree: a zero-th share of the bandwidth is 0, it makes sense semantically.

I think the counterargument would be you are supposed to use a dependency chain for ordering the responses. And assuming that is the case, I think I prefer not diverting from what we do in HTTP/2 in minor ways, because that would cause confusion among the users of HTTP.

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