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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24C5B126BED for <>; Thu, 29 Nov 2018 19:23:09 -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 eGG6eQZCSt8D for <>; Thu, 29 Nov 2018 19:23:07 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 750BB12008A for <>; Thu, 29 Nov 2018 19:23:07 -0800 (PST)
Date: Thu, 29 Nov 2018 19:23:06 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1543548186; bh=J48Vs7Ob36BLlyH7SflnUGUdoJ56S1obkvBwSMnYXB8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=oVH3GbB64Dh1tpAs1p+Z9jL/MpBYvP5+R0gymR1aX0JIoD0eb7zFIe6yqYVDnzdSP CDNNxY0lvXePG84bpgTOGjxjq8HB4w3gbJ+rN/dBNeHUUOv7OMflMf+SgnD3cFapTT 8ZLUltDDIwAONhhBitHOT5xRmC9mp8+N47hFdkaw=
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_5c00ad1a9a8af_61943fa239cd45b8522953"; 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:23:09 -0000

I understand the argument about sudden increases when the ack_delay is increased... but that is exactly my point as well. It's easy to see a sudden decrease in latest_rtt with the patch when ack_delay is increased.

Consider a clock adjustment at the client where the clock "caught up" with real time (I've seen this happen), and the reported ack_delay is quite large. If the actual RTT had departed a fair bit from min_rtt, then this single misreported ack_delay will cause the sender's estimate of latest_rtt to drop to min_rtt.

As @ianswett  notes, what matters is where this erroneous value -- too small or too large -- gets used. It's used in RTO, TLP, and perhaps in pacing. My argument is that having too large a value -- as would happen with the spec -- is better than having too small a value, because that's the conservative thing to do.

For context, we should be mindful that any sudden and occasional increase/decrease in ack_delay is easily absorbed by the RTT filters; that's in fact exactly why the EWMA filter is weighted as it is. Any single sample does not change the SRTT or RTTVAR by much. Individual samples can be noisy. Ultimately, as long as it's an RTT spike, it actually doesn't matter much. It only matters if it's persistent.

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