Re: [quicwg/base-drafts] It seems the minimal packet number length should be 14 bits (#2955)

Luo Kai <> Tue, 06 August 2019 08:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 441B5120140 for <>; Tue, 6 Aug 2019 01:35:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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 F9TjfrD4e33v for <>; Tue, 6 Aug 2019 01:35:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 67FEA120131 for <>; Tue, 6 Aug 2019 01:35:06 -0700 (PDT)
Date: Tue, 06 Aug 2019 01:35:05 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1565080505; bh=NEk2ZoNj6bj/+PyOQcq8YEwXcMES8puguGidWsaoq00=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=NxhgQ/fb8Bl2uGxZfV6lK4FcSL+wjQtp4HVh8CH98x/IGjOe7b4TfxSXnNhaJDXXX 9Pb/BY/p8iI4gXC5RgSJyDHGiH/CgN+kHEfOc6MzYSwMzhJ01Cq4eqkPXb61mWD90A nfwsX5IuAx757TcmX4OfbxNxcSynRsIfJmtosmYY=
From: Luo Kai <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2955/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] It seems the minimal packet number length should be 14 bits (#2955)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d493bb981ebb_7ff13fb65e0cd95c286761"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: NKTelnet
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: Tue, 06 Aug 2019 08:35:08 -0000

> First, there is no 7-bit encoding. It's 8 bits, 16, 24, and 32.
> Also, there is no guarantee that following the advice in the spec is sufficient either. You can diligently follow the spec requirements and still have <1RTT worth of reordering cause problems if you suddenly increase the rate of sending packets. If you were sending 8-bit packet numbers, then you suddenly send far more than 128 packets within an RTT, a strict interpretation of the spec might still lead to most of those packets being sent with 8-bit packet numbers. If any of those packets with 8-bit numbers is reordered/delayed by more than 127 packets, then it will be decoded incorrectly when it arrives.
> That leads to spurious loss, which is repaired very quickly, but it is less than optimal. To do this perfectly, you have to predict future send rates, which is hard.
> But we have discussed this in the past. I don't see any new information either. I'm going to recommend no action on this one.

Yes, I saw the encoding bits number has been changed to 8, 16, 24, 32. So this issue will only happen when more than 128 packets number is reordered. 

I can not understand what “That leads to spurious loss, which is repaired very quickly” means.

Once this issue happens, the related connection may be idle for ever and can not be recovered any more.

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