Re: [quicwg/base-drafts] max_ack_delay is unknown when a new connection is established (#2638)

Kazuho Oku <> Tue, 23 April 2019 00:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C4413120026 for <>; Mon, 22 Apr 2019 17:31:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.597
X-Spam-Status: No, score=-6.597 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_28=1.404, 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 YEQISJHPYqAI for <>; Mon, 22 Apr 2019 17:31:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4C228120126 for <>; Mon, 22 Apr 2019 17:31:32 -0700 (PDT)
Date: Mon, 22 Apr 2019 17:31:31 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1555979491; bh=yx+QQUGQJltKUEt3FRj1QYf4BHvClWCg7bWsc+9Q1g4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=OnkxkBXRaRKc/qUqcaFnnbcrC7h5psFXZ+Z4nOiMPrP5W/RvKudMvcPrSonrAgF77 PHSUEudc68oLvxn7FV66h0KV0ZKIMNBPoB3pgpHY881TTK0TDVve28zzfYWuHGcz9k pRY50cxB+KGmnJIrFf94jGN2W5yFfDnkenGVpoSA=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2638/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] max_ack_delay is unknown when a new connection is established (#2638)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cbe5ce361a1c_4c363fcdaf8cd9641294e5"; 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: Tue, 23 Apr 2019 00:31:34 -0000

I'd argue that we should use 0 until receiving TP.

We require endpoints to send ACKs for crypto packets immediately. That means that the ack-delay value found in the ACK packet is something that the peer could not control. It is my understanding that we consider these uncontrollable delays induced within an endpoint as part of RTT.

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