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

ianswett <> Wed, 24 April 2019 14:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 77A5D1201E5 for <>; Wed, 24 Apr 2019 07:01:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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_PASS=-0.001, URIBL_BLOCKED=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 x8oKKIL9fcM8 for <>; Wed, 24 Apr 2019 07:01:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6B7CB12029F for <>; Wed, 24 Apr 2019 07:01:39 -0700 (PDT)
Date: Wed, 24 Apr 2019 07:01:38 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1556114498; bh=00j5hLpPv284hti3zXInjupVNxSOx1vv/1DsSo+cOHo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=OUOfLYbGFLnc0YMo27Yb1Yjxvx76QS7BoiN6oxOLmdb074rX2GtO6c+Nzq/p45HFT jUVtePm1XW20z0P7xJv9YuxxPEfpoaRJ6r2x+jr7IsRDKAOUavz6jy5LcUxicbalts Ne4E7dJgWAoB7N7JzkJtYI630phx9jVzS+BAkgAw=
From: ianswett <>
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_5cc06c424c7ae_a393fbaed2cd96c49798a"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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, 24 Apr 2019 14:01:48 -0000

The crypto retransmission timer doesn't use max_ack_delay intentionally, see:

 "In order to quickly complete the handshake and avoid spurious
   retransmissions due to crypto retransmission timeouts, crypto packets
   SHOULD use a very short ack delay, such as the local timer
   granularity.  ACK frames SHOULD be sent immediately when the crypto
   stack indicates all data for that packet number space has been

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