Re: [quicwg/base-drafts] compensation of ack_delay is fragile against errors (#2060)

ianswett <> Fri, 30 November 2018 02:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E53A512F1AB for <>; Thu, 29 Nov 2018 18:18:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.46
X-Spam-Status: No, score=-9.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, 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 eu0ALiLunmYa for <>; Thu, 29 Nov 2018 18:18:40 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0DEE312D4E7 for <>; Thu, 29 Nov 2018 18:18:39 -0800 (PST)
Date: Thu, 29 Nov 2018 18:18:38 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1543544318; bh=Rpdhqd7JE6O9Yax0lz8sE+x+Cw/KThfa3Iwcehv7pgw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=S6Q95nE4ah8lMRnqJsy7avmxMxIYtyb6CgXCuy77+cca/7+pVh2eqIFQjXx+/vPPG JgFiHKzy8q2jwRGUjerBpf7j93wwEGjh7BvE0VoPnpcr8yiqKmn17J4ySwgtJjYH+z nwqJY4QxL2sImShsBI7yqFVYpBKZf5a2TzFDQSh4=
From: ianswett <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2060/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] compensation of ack_delay is fragile against errors (#2060)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c009dfed98ef_10c73faa1e0d45b4303413"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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: Fri, 30 Nov 2018 02:18:42 -0000

In regards to min(ack_delay, max_ack_delay), it's critical to consider what srtt is used for, which is loss detection and timers(TLP and RTO).

If there is a high rate of ACK loss or if the peer's alarms are persistently waking up late, then the SRTT and/or RTTVar will increase, thereby increasing these timers.  If this happens very infrequently, then the EWMA will forget them relatively quickly.  I think that seems appropriate?

To think of the pathological case, what if a peer communicates a max_ack_delay of 0?  I think it's important the rest of the recovery machinery still functions correctly in that case.

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