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

Kazuho Oku <> Thu, 29 November 2018 05:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C20D12426A for <>; Wed, 28 Nov 2018 21:04:03 -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 blUD1hJGJIy4 for <>; Wed, 28 Nov 2018 21:04:01 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 20DD612785F for <>; Wed, 28 Nov 2018 21:04:00 -0800 (PST)
Date: Wed, 28 Nov 2018 21:04:00 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1543467840; bh=MfKvWK4RhoiS71v3niIb7TALmiexEZLLdI/RTWTgd2c=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=SDvaZzGZenslcaIQ8eHlSBWIF4K1bRIFoNzRsjN34316aFE5nGfIGSYb3szTBEydL KsNqF0yj45NxYdhJTdvmB/t9FvGlgeeb8FBZyOsDHJtV0GDjltJYOCwPTNIzPSdn3f THXm/BGNsPc/81mqf1tCptPK/PbK7fWth4+mvOgg=
From: Kazuho Oku <>
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_5bff734026236_346d3fbc2ead45c4426027"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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: Thu, 29 Nov 2018 05:04:03 -0000

> I'm concerned that if the ack_delay being reported is too large, I don't know how much of that is in error and how much of that is accurate. The patch assumes that exactly latest_rtt - min_rtt is the correct ack_delay, but there's no evidence of it.

I do not think that that is an issue, because we always use `max(srtt, latest_rtt)` for loss recovery. Things would work fine as long as SRTT does not become too small.

If it is the case that the clock has a jitter, the observed SRTT using the proposed formula will end up in a value that is either equal to or slightly higher than the true SRTT.

If it is the case that the clock occasionally jumps (to adjust time), the observed SRTT using the proposed formula would also be either equal to or slightly higher than the true SRTT.

So I would assume that the proposed formula has no issues in the cases above.

> The problem with the proposed patch is that a client that reports an ack_delay that is too large will automatically cause the sender to always believe that the RTT is not growing at all. (Imagine the case where ack_delay is always reported as MAX_INT. This means that the sender will always end up with latest_rtt = min_rtt.)

I can understand your concern about broken implementations, but I am not sure if the current defense is good enough if it is the case that we need to make care of them. Consider the case of an endpoint that always set `ack_delay` to 25ms. Assuming that the true RTT is greater than that value, the observed RTT will be 25ms less than the true value.

To put it another way, it seems to me that there is no reliable way of detecting peers sending broken `ack_delay` values. IMO we should accept that QUIC would not work fine with broken stacks.

Or alternatively, we might want to state that QUIC stacks running with an unreliable clock SHOULD set `ack_delay` to zero.

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