Re: [quicwg/base-drafts] Fixing max_ack_delay (#3938)

Kazuho Oku <> Thu, 13 August 2020 02:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3913C3A15C6 for <>; Wed, 12 Aug 2020 19:41:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Status: No, score=-1.697 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, 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 P_BpQozqvgAv for <>; Wed, 12 Aug 2020 19:41:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C7D093A15C3 for <>; Wed, 12 Aug 2020 19:41:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 78C8D600ADB for <>; Wed, 12 Aug 2020 19:41:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1597286469; bh=B/agAtP2Rm+lqeSAXux7/o+Lh7dP1g1mwp1DvMDobzM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=G3mHDhAq1iwBcUwp0zlYbLp1ec1r2Q4KYScHfrJGzNwMWchYkh7LSwL1/qLAXXu3r f6+8inz6Biz3CHLjr1wKlZ522wFgUzA0jrn0OQhncI9SwP5pI+Xx1RqIUP9GmQrc/X ypLxYkOm3oEfJ5ojAISMi41oziOq3GRKreZe6vEI=
Date: Wed, 12 Aug 2020 19:41:09 -0700
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3938/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Fixing max_ack_delay (#3938)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f34a84568b92_243516f8346228"; 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: Thu, 13 Aug 2020 02:41:12 -0000

@kazuho commented on this pull request.

I am not sure if we want to adopt this PR (in current form).

> @@ -1094,7 +1094,9 @@ max_ack_delay:
 : The maximum amount of time by which the receiver intends to delay
   acknowledgments for packets in the Application Data packet number space. The
   actual ack_delay in a received ACK frame may be larger due to late timers,
-  reordering, or lost ACK frames.
+  reordering, or lost ACK frames. max_ack_delay is initialized to 0 and
+  updated when transport parameters are exchanged. If a peer does not
+  specify max_ack_delay, it is set to 25ms.

As @martinthomson points out, this is a deviation from the definition of max_ack_delay in the transport draft, that says that the value defaults to 25ms and is updated when receiving the transport parameters from the peer.

We could have different definitions, but IMO it is unnecessary in this case, based on our agreement that persistent congestion is a connection-wide event and that it can be applied during the handshake.

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