Re: [quicwg/base-drafts] Add max_bytes_before_ack to transport (#1715)

Christian Huitema <> Thu, 30 August 2018 16:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 924A7130DC2 for <>; Thu, 30 Aug 2018 09:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.009
X-Spam-Status: No, score=-8.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 t1AGbkqha8A7 for <>; Thu, 30 Aug 2018 09:28:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 43667127148 for <>; Thu, 30 Aug 2018 09:28:59 -0700 (PDT)
Date: Thu, 30 Aug 2018 09:28:57 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1535646537; bh=ydYlhnRwWmQHX46aTzGv5QPU4E/av/b5GypFSTmO3kI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=jx/x50GRl5c/MUmGT+aCFwDNm+moAaeJzTLJIc58WbhVSKGWLJh5gNGq+f8sJmnD2 HAW4inOTASWShZ2oEb0f2rwpPPJJvUmXiPvpL2Rkv7YTN0tnhZ3Y9YB6jrhPcHaSuv zu1mbKySSk9u4/N7mZzpksPGqrspaBiy24MDltQk=
From: Christian Huitema <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/1715/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Add max_bytes_before_ack to transport (#1715)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b881b4942263_62be3f8943cd45b8245784"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.27
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, 30 Aug 2018 16:29:02 -0000

huitema commented on this pull request.

I am not enthusiastic about that. It feels like a spur-of-the-moment addition. I am not sure that it solves a real problem, compared to a time based approach. Also, if we did add something like that, we may want a way to tune the variable during the lifetime of the connection.

> @@ -1671,6 +1672,13 @@ disable_migration (0x0009):
   address other than that used to perform the handshake.  This parameter is a
   zero-length value.
+max_bytes_before_ack (0x000c):
+: An unsigned 32-bit integer that indicates the maximum number of bytes received
+  before an ACK frame should be sent. The peer sending this value indicates
+  to the receiver the value it should use.  If this value is absent, the
+  receiver may use any conformant acknowledgement algorithm.

The current algorithms are either time based or packet based, requiring for example several ACKs per RTT, and specifying a maximum delay or a maximum number of packets before an ACK will be sent. What is the rationale for adding a byte based control? Also, given that the algorithms are time based or packet based, why not specify max_packets_before_ack, or max_ack_delay?

> @@ -3425,6 +3433,13 @@ immediately or when a delayed ack timer expires. The delayed ack timer MUST
 NOT delay an ACK for longer than an RTT, which ensures an ACK frame is sent
 at least once per RTT if new packets needing acknowledgement were received.
+If the max_bytes_before_ack transport parameter has been received, the
+receiver SHOULD send an ACK frame immediately when at least that many octets
+of packets containing frames besides ACK or PADDING have been received since
+sending the previous ACK frame. If a receiver sends ACK frames less frequently,
+it risks causing the sender to send more slowly, which may lower the delivery
+rate at the receiver.

This is not free. It comes in addition to existing logic which is already designed to prevent sender starvation. It requires at least one additional counter in the connection state, i.e., "max bytes sent at the last ACK time", and of course additional tests in the ACK sending logic. 

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