Re: [quicwg/base-drafts] SHOULD NOT include platform delay in ack delay (#2786)

Kazuho Oku <> Fri, 14 June 2019 16:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BEC801205FC for <>; Fri, 14 Jun 2019 09:50:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.391
X-Spam-Status: No, score=-6.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 1qCqgXPxPDgA for <>; Fri, 14 Jun 2019 09:50:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4FE80120662 for <>; Fri, 14 Jun 2019 09:50:36 -0700 (PDT)
Date: Fri, 14 Jun 2019 09:50:34 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1560531034; bh=3mSocXE22gsi+qaZ56mc6O71EnF8m/w30eT1fFSkTvE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Vl88Tmzev1gZyykLd9TkA+3bv+OWLswEvu+rVzII1vxtmlBzp7oi7zAwZXPI+80g8 H9wsWvppSXEdgJTG77hagKg4An8JYPM/2trupSiy998UksZgMLrWmESUez1Y01Qk80 AyuqG+wEOkm/wg8c+FxY+xFYyQlKWxDwWo+LCihU=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2786/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] SHOULD NOT include platform delay in ack delay (#2786)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d03d05ab00e5_68a63fb9512cd964358791"; 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: Fri, 14 Jun 2019 16:50:41 -0000

_I_ think that theoretically, decryption delay is not intentional (i.e. something an endpoint has opted in to add) and that therefore it should not be part of ACK delay. OTOH, processing of TLS handshake is about processing the payload of a "stream." That's something happening above the packet-level processing and ACK generation layer, and therefore it should be considered as part of the ACK delay. Note also that you can offload the handshake processing to a different thread or start the processing after you send an ACK.

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