[quicwg/base-drafts] Is ACK delay zero for Initial and Handshake ACK frames? (#3459)

Lars Eggert <notifications@github.com> Fri, 14 February 2020 07:31 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 B316012008C for <quic-issues@ietfa.amsl.com>; Thu, 13 Feb 2020 23:31:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Level:
X-Spam-Status: No, score=-6.382 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_24=1.618, 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: 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 L6EPfqGtjOph for <quic-issues@ietfa.amsl.com>; Thu, 13 Feb 2020 23:31:48 -0800 (PST)
Received: from out-20.smtp.github.com (out-20.smtp.github.com [192.30.252.203]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB2C412009C for <quic-issues@ietf.org>; Thu, 13 Feb 2020 23:31:47 -0800 (PST)
Date: Thu, 13 Feb 2020 23:31:47 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1581665507; bh=PzIByzAY4rrW8R8VMPVuXSWFkSi0YZc6GtadLa3DaTw=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=mqlB9gU9UVr8uY7HgKxJiNS7SvbzV9DmN7DXo9u/ZhlTDdIgu4cPfWi4CNFvalyzl 5y9vvP4O38+o+xQThDnAksZbrEhdjLo71sxMF3BCkfksOpZS9Tjtjw5PreEpaJKyII UIhp2MNxaTIIAupma3y2qckr/KQkF26KqsW6xKgs=
From: Lars Eggert <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3V3DNBQSNHBNHE77N4KN7WFEVBNHHCDL4S2A@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3459@github.com>
Subject: [quicwg/base-drafts] Is ACK delay zero for Initial and Handshake ACK frames? (#3459)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e464ce31cae_52f23fa8a1acd9683405e0"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: larseggert
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/c9j6dLz3G4TPcDrpegzslPDPW0E>
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: Fri, 14 Feb 2020 07:31:50 -0000

Section 5.2.1 of -recovery-25 says:

>   When the PTO is armed for Initial or Handshake packet number spaces,
>   the max_ack_delay is 0, as specified in 13.2.5 of [QUIC-TRANSPORT].

However, Section 13.2.5 of -transport-25 doesn't actually say that (anymore?) Section 13.2.1 says

> For Initial and Handshake packets, a max_ack_delay of 0 is used.

so I guess at least the reference is incorrect.

But since Section 19.3 only has a SHOULD for encoding zero

>   Because the receiver
>      doesn't use the ACK Delay for Initial and Handshake packets, a
>      sender SHOULD send a value of 0.

and the pseudo code simply uses the encoded ACK delay, if the ACK sender doesn't encode zero, the ACK receiver will compute its RTT based on the encoded ACK delay.

-- 
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/3459