Re: [quicwg/base-drafts] VN packets may be dropped more often when the QUIC bit is 0 (#2400)

Kazuho Oku <> Fri, 08 February 2019 04:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A19DE130F23 for <>; Thu, 7 Feb 2019 20:03:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Status: No, score=-8.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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] 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 AUDqBql8cUuB for <>; Thu, 7 Feb 2019 20:03:05 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D913B128B01 for <>; Thu, 7 Feb 2019 20:03:04 -0800 (PST)
Date: Thu, 07 Feb 2019 20:03:03 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1549598583; bh=KUBmKwQI3yunsGpSDGlKaLnP6Y5l+bUmC66y8Ox/Eww=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Z13hzyJ5mXdLsb2xj5acZfa4vuMN/dAj3I42o+/dwEvtsE2ek869eXwuTvvs6FOyC XReZfUoi8kWdflQJZEFCQoLCQKoIBqAb33HvVfJiI4rQtbwrLt7Su+P6UIwvMSpylX RBIsEralxWePAWUqFllA7CsJyBQpDHUg0r0zfegM=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2400/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] VN packets may be dropped more often when the QUIC bit is 0 (#2400)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c5cff7785527_648a3fb2898d45c0592f0"; 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, 08 Feb 2019 04:03:07 -0000

I agree that the long header packets sent by the client needs to have the QUIC bit set.

I also agree that there's less need to have the bit set in the long header packets sent by the server, though I think it's possible to argue that we should not have different requirements based on the role, because QUIC does not have a distinguish a client address tuple and a server address tuple (i.e. an endpoint can use a one address tuple for accepting connections and also for initiating connections as a client).

For short header packets, I think we agree that the bit is not required. Then the question is, assuming that we decide to kill the bit, should we grease it, or rather, change it to a reserve bit? I suggest the latter because changing the definition to "reserved" and covering the bit using header protection is the strongest way of preserving the freedom to use the bit in future versions of QUIC. It can also be considered as a simplification, because there would be not need to "randomize" the bit for greasing; endpoints can rely on the header protection to flip the bits.

FWIW, current definition of the short header first byte is: `0 1 S R R K P P`. This would change to `0 S R R R K P P` if we are going to change the QUIC bit to a reserved bit.

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