Re: [quicwg/base-drafts] Ack Delay and TLP (#1796)

MikkelFJ <> Tue, 02 October 2018 15:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34042130E9F for <>; Tue, 2 Oct 2018 08:21:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.456
X-Spam-Status: No, score=-8.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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] 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 3pVRggCVv9o4 for <>; Tue, 2 Oct 2018 08:21:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BE7C0130E16 for <>; Tue, 2 Oct 2018 08:21:38 -0700 (PDT)
Date: Tue, 02 Oct 2018 08:21:37 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1538493697; bh=45lmKBA7YlQdAqQdYrOyVKGloINGuaokUVasKPeC7DY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=p/WzjSEgagNuiJkF0RR6bsBS/mX10v2jJgxtl3/Q02z7Kw2Ki6UIW/6qqS/FMgPaL symDRo75F3K0r+IMa7JfMQgxY3PM1HxttytNoc4d55/ERVLO1cyH79B7WLkPTL9nCV KTzSP4l338E9orQwIzGVIJvu+y9azPsje8SaxODo=
From: MikkelFJ <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/1796/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Ack Delay and TLP (#1796)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bb38d01e535b_41a13fa1218d45bc2617df"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
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: Tue, 02 Oct 2018 15:21:41 -0000

mikkelfj commented on this pull request.

> -or ACN_ECN.  Specifically, implementations MUST attempt to enforce a maximum
-ack delay to avoid causing the peer spurious timeouts.  The RECOMMENDED maximum
-ack delay in QUIC is 25ms.
-An acknowledgement MAY be sent for every second full-sized packet, as TCP does
-{{?RFC5681}}, or may be sent less frequently, as long as the delay does not
-exceed the maximum ack delay.  QUIC recovery algorithms do not assume the peer
+excessively delay acknowledgements of packets containing frames other than ACK.
+Specifically, implementations MUST attempt to enforce a maximum
+ack delay to avoid causing the peer spurious timeouts.  The maximum ack delay
+is communicated in the `max_ack_delay` transport parameter and the default
+value is 25ms.
+An acknowledgement SHOULD be sent immediately upon receiving two or more
+retransmitable full-sized packets, as TCP does {{?RFC5681}}.  QUIC recovery
+algorithms, including tail loss probe{{tail-loss-probe}}, assume the peer

How do you define full-sized packets when this depends on PMTU discovery?
The text also isn't very clear about receiving drips of full sized packets: can you ack after only one full packet if it exceeds max ACK delay? I'd say obviously yes, but I'm sure the text is very clear (before or ofter this change).

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