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

Martin Thomson <notifications@github.com> Tue, 06 August 2019 07:52 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D571E120059 for <quic-issues@ietfa.amsl.com>; Tue, 6 Aug 2019 00:52:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.597
X-Spam-Level:
X-Spam-Status: No, score=-6.597 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_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzGihRQOMykK for <quic-issues@ietfa.amsl.com>; Tue, 6 Aug 2019 00:52:12 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4BC8120044 for <quic-issues@ietf.org>; Tue, 6 Aug 2019 00:52:11 -0700 (PDT)
Date: Tue, 06 Aug 2019 00:52:11 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1565077931; bh=JPaqeYB3WJJ4IfdPSalxCIjeJvo01ALiGqMUvd7R7YI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=UGQCxZ76ncvjfLW9mc5OFcNWbAdZbr6SQaQJAHsnkM8knli7z8JYg8vmlKmskhCKl SIY/u30PriKX0k99J/bWHJkt45pPXFPPWNHhBkhaoPVPcIUUXiRJIcDwy1dvg64OcM MmU70hmSSY9Ee/wbcmmjW7Y8PLTc7SnwKIfS8eEg=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5JYGEUKHWXGKA2AON3KZSCXEVBNHHBY4E7DY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2955/518553022@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2955@github.com>
References: <quicwg/base-drafts/issues/2955@github.com>
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_5d4931ab358aa_53c3f89960cd960714b2"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/iBLBLrjDqbT5Lg3dp-3xSmFSy8k>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Aug 2019 07:52:14 -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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2955#issuecomment-518553022