[quicwg/base-drafts] Ignoring ACK delay can result in wrong RTT calculations (#3350)

kixelated <notifications@github.com> Wed, 15 January 2020 20:01 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E85E21209E6 for <quic-issues@ietfa.amsl.com>; Wed, 15 Jan 2020 12:01:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id EITo6eA5QczT for <quic-issues@ietfa.amsl.com>; Wed, 15 Jan 2020 12:01:10 -0800 (PST)
Received: from out-23.smtp.github.com (out-23.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CB30120C85 for <quic-issues@ietf.org>; Wed, 15 Jan 2020 12:00:51 -0800 (PST)
Received: from github-lowworker-56fcc46.va3-iad.github.net (github-lowworker-56fcc46.va3-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id AB29F660E2F for <quic-issues@ietf.org>; Wed, 15 Jan 2020 12:00:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1579118450; bh=QZERpsiabjLEhTXPNQPOFaV+ItpU1XkZZW5rQBU9F3U=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=i4c6fSeGGC0Aviela63/yWxCyNnhA5X70cts2OGXkQFHRYvyQJDXEPgANzaVeaezA 3eXyUAGA4XZo6o8JSdmeYC7oqykGMlVyw2BJZtatOoyxLUGPlBHKn2SF71/AkFX3ij FUmitb52IRJWLG/8INJLp8hU/nKKn3QZ+yNiTtb4=
Date: Wed, 15 Jan 2020 12:00:50 -0800
From: kixelated <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7XVEC23VL75LSVUBF4FSQ7FEVBNHHCBTTN5I@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3350@github.com>
Subject: [quicwg/base-drafts] Ignoring ACK delay can result in wrong RTT calculations (#3350)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e1f6f729bdf8_560b3fcd3a6cd968157440"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kixelated
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/Uxuf7YrjLI3krw6tG2ThMYG9tqc>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2020 20:01:17 -0000

I'm implementing the RTT estimation code in quic-recovery at the moment and I've run into a potential edge case with ACK delays. This is entirely hypothetical for the moment.

For example, suppose `min_rtt = 100` and our actual round trip time is 99ms, 100ms, or 101ms with equal frequency. This minimum RTT was calculated earlier (ex. handshake) but now the peer is delaying ACKs.

If we receive an ACK with `latest_rtt = 126` and `ack_delay = 25`, then `adjusted_rtt = 101`.
If we receive an ACK with `latest_rtt = 125` and `ack_delay = 25`, then `adjusted_rtt = 125`.
If we receive an ACK with `latest_rtt = 124` and `ack_delay = 25`, then `adjusted_rtt = 124`.

The computed result is `smoothed_rtt=117` and `rttvar=11`.
The "actual" result should be closer to `smoothed_rtt=100` and `rttvar=2/3`.

Any delayed ACKs sent faster than `min_rtt` will skew the results based on the `ack_delay`. This includes ACKs sent over a faster path. 

These RTT estimates can be brought closer to reality with a more accurate `min_rtt`. This can only be accomplished if the peer transmits an ACK with `ack_delay=0` and gets lucky.

However, a peer will only send an immediate ACK if it receives two ack-eliciting packets within `max_ack_delay` of each other (and the peer follows the RFC recommendation). Ironically, this is the situation where estimating the RTT is the most important, as the packet rate is too low for fast recovery.

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