Some questions about Packet Number Encoding And Decoding

mikewczhou(周雯程) <mikewczhou@tencent.com> Tue, 03 September 2019 03:27 UTC

Return-Path: <mikewczhou@tencent.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3A91200CC for <quic@ietfa.amsl.com>; Mon, 2 Sep 2019 20:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 wkBKVnmczlJ0 for <quic@ietfa.amsl.com>; Mon, 2 Sep 2019 20:26:56 -0700 (PDT)
Received: from mail4.tencent.com (mail4.tencent.com [183.57.53.109]) by ietfa.amsl.com (Postfix) with ESMTP id 7B490120041 for <quic@ietf.org>; Mon, 2 Sep 2019 20:26:45 -0700 (PDT)
Received: from EXHUB-SZMail01.tencent.com (unknown [10.14.6.21]) by mail4.tencent.com (Postfix) with ESMTP id C13C950646 for <quic@ietf.org>; Tue, 3 Sep 2019 11:26:43 +0800 (CST)
Received: from EXMBX-SZ059.tencent.com ([fe80::94d8:6d35:fe09:c628]) by EXHUB-SZMail01.tencent.com ([::1]) with mapi id 14.03.0415.000; Tue, 3 Sep 2019 11:26:43 +0800
From: "mikewczhou(周雯程)" <mikewczhou@tencent.com>
To: "quic@ietf.org" <quic@ietf.org>
Subject: Some questions about Packet Number Encoding And Decoding
Thread-Topic: Some questions about Packet Number Encoding And Decoding
Thread-Index: AQHVYgdn4TYZAI9nOkGor2I93/Ddhg==
Date: Tue, 03 Sep 2019 03:26:42 +0000
Message-ID: <2739D40F-AD57-4B98-8515-472D37113035@tencent.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.14.87.251]
Content-Type: multipart/alternative; boundary="_000_2739D40FAD574B988515472D37113035tencentcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/2PEy_AaBTzA8azKWhbYSFUgh-nQ>
X-Mailman-Approved-At: Mon, 02 Sep 2019 21:23:06 -0700
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Sep 2019 04:07:49 -0000

Thank you guys a lot! I have some questions about Packet Number Encoding And Decoding
In transport draft Section 17.1. Packet Number Encoding and Decoding
For example, if an endpoint has received an acknowledgment for packet 0xabe8bc, sending a packet with a number of 0xac5c02 requires a packet number encoding with 16 bits or more; whereas the 24-bit packet number encoding is needed to send a packet with a number of 0xace8fe.

  1.  What's the purpose of Packet Number Encoding? to be safe or save some bits space or something else?
A peer receiving the packet will then correctly decode the packet number, unless the packet is delayed in transit such that it arrives after many higher-numbered packets have been received. An endpoint SHOULD use a large enough packet number encoding to allow the packet number to be recovered even if the packet arrives after packets that are sent afterwards.

  1.  How can an endpoint know to use a large enough packet number encoding? For example, as example 1 said, an endpoint can send 16 bits to send a number of 0xac5c02 if peer has received an acknowledgment for packet 0xabe8bc, which means it will send 0x5c02. So in the early time when it want to send 0x5c02 exactly(not 0xac5c02), How should it encode packet number to avoid conflict with 0xac5c02 if the packet is delay so much.
  2.  If an endpoint is not encoded packet number well, the peer will recover it as a wrong packet number, what happens next?