Re: [quicwg/base-drafts] Reduce restrictions on valid RTT samples (#2568)

Jana Iyengar <> Wed, 03 April 2019 19:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B93F120178 for <>; Wed, 3 Apr 2019 12:38:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.002
X-Spam-Status: No, score=-8.002 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_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 cNKKMn4RhzL4 for <>; Wed, 3 Apr 2019 12:38:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 884CF12016D for <>; Wed, 3 Apr 2019 12:38:28 -0700 (PDT)
Date: Wed, 03 Apr 2019 12:38:27 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1554320307; bh=uOYrjMLoi12kTlkZjCj4ipL6z9G4RTyD9VA7pR7X+aY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=U3Zt14/9CN5ybIwPTooXY15V9RUVcQVOg0W6/m35LSMLkkVtI0vkrJVM0gEmAJ22s alrPSD+XpapjipMXbau3sLvKk8PXS2w27smC5Dh+XvLdYApphnFvfwDNZINRLuqMim +uw2kO2+5KIIIGYncXSOhiUuCbykrp7e6oMF/Ygo=
From: Jana Iyengar <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2568/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Reduce restrictions on valid RTT samples (#2568)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ca50bb35a5a9_39623f9a350d45bc2255fa"; 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: Wed, 03 Apr 2019 19:38:31 -0000

I've been doing more thinking, and here's where I've landed. (Thanks @kazuho and @ianswett for conversations.)

The higher order principle is this: max_ack_delay suggests a contract between this endpoint and its peer. The peer is supposed to send ACKs for ack-eliciting frames within max_ack_delay amount of time. Effectively, the peer _wants_ to wait for no more than max_ack_delay amount of time, but if the actual received ack_delay is larger (due to ack loss or scheduler latency), the RTT should be increased to compensate for this additional delay beyond max_ack_delay, because it's not within the peer's control and we might consider it part of "path" delay.

With this principle in place, I think it still makes sense to make the first change I proposed: that an ACK should be used for RTT measurement if any packet it newly acks is ack-eliciting. The RTT measurement is still on the largest_acked (since ack-delay is reported for the largest_acked).

It is difficult to reason about ACKs that only ack non-ack-eliciting packets, since the max_ack_delay contract does not hold. It is specifically difficult to reason about the reported ack_delays, since the peer can wait arbitrarily long and report arbitrarily long ack_delays. It's incorrect to add any additional delays (beyond max_ack_delay) into the RTT since the increased delay was not due to uncontrollable circumstances. Simply using the ack_delay, however large it may be, allows for the peer to simply game the RTT.  Using only the samples that have ack_delay < max_ack_delay might introduce a bias. It gets complicated quickly.

So, I conclude that we should not use ACKs of non-ack-eliciting packets for RTT measurement. This is what we do right now, so that's good. I'll add some text explaining why.

We should also recommend that an endpoint that is only sending non-ack-eliciting packets should piggyback a PING frame along with an ACK roughly once an RTT so that its RTT estimate is reasonably current.

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