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

janaiyengar <> Fri, 30 November 2018 03:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 415BF12008A for <>; Thu, 29 Nov 2018 19:09:19 -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 HNQpKflvZnK7 for <>; Thu, 29 Nov 2018 19:09:17 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AFB93126C01 for <>; Thu, 29 Nov 2018 19:09:17 -0800 (PST)
Date: Thu, 29 Nov 2018 19:09:17 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1543547357; bh=0Ipjp+GEqqhgC81h9m6YzcO3k4W7huNZ0T3EStdafwk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=lehDlOw4MYUg9GAJ4etoZ6lsMH5h76N1h6GK8/DF1hC+AmwEpQvYOwZjoH+9rqhc6 xClfBlAM0EfSDrD3hbVpz8SP2QNbwDu7+O9pI45nxugekNBVeD3bVVIAK5npWiBokb GumfByzso08sh4k+tR9BfnRa2lQMF89uNbcQFac4=
From: janaiyengar <>
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_5c00a9dd28c07_786a3f9c74ad45bc453219"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: janaiyengar
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 03:09:19 -0000

Responding to the most recent couple of comments first: SRTT does not include ack_delay, which is why we add max_ack_delay back into the RTO computation. So, even in the case of ack loss, the SRTT *should* be the same... the reported ack_delay might keep increasing.

There is the question of what to do if ack_delay gets larger than max_ack_delay, which is why I had argued that should prefer observed ack_delays over explicitly stated ones (in an earlier thread.) I think we had discussed monitoring ack_delays and using that value over time, but left it for later...
ideally, we'd use an EWMA or some such to track actual ack_delays to see if they're increasing, and add that into the RTO computation.

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