Re: [quicwg/base-drafts] Remove ack_delay_exponent TP (#2670)

Kazuho Oku <> Tue, 09 July 2019 23:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34F5A120089 for <>; Tue, 9 Jul 2019 16:53:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 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, SPF_HELO_NONE=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 XJdFablXm9IM for <>; Tue, 9 Jul 2019 16:53:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EDA0F1200C3 for <>; Tue, 9 Jul 2019 16:53:29 -0700 (PDT)
Date: Tue, 09 Jul 2019 16:53:28 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1562716408; bh=oDs2DHc5Z1BBi1vlODNHxaNNxdI9UdXKSPtEzBs863Y=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=p49yrQAeDfG02BUiYmufFhHEPp24y/3bkvybhkpV08gzmIn0o6NmMGjozL4vjIyLK zrTckx/keQFf0bQobQzrXtVcmbUtlSmYCPQ0QTrxeVLdUN1M5i0Qd3VrdlzkpvytQy O3g5wU9s1YgI9V9m2zQp3SRy+nHpaHLWV6oKOd4w=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2670/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Remove ack_delay_exponent TP (#2670)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d2528f8a4237_24163f8032ecd9608632b3"; 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, 09 Jul 2019 23:53:32 -0000

Doing a hum sounds good to me. Mp prefeence goes to arguing for dislikes as @ianswett says.

> As I understand the state of play, the main costs are bytes on the wire (potentially across a wide range of operating points: short RTT, fast processor to long RTT, slow processor), code complexity, and efficiency of calculating the values for encode (e.g., division vs. shift) or decode (e.g., multiply vs. shift).

FWIW, this is the table I have illustrating the differences of the encoder side. I do not think division is necessary even when adopt the multiplier proposal, because the encoder has the freedom to choose the multiplier. By choosing a multiplier that is 2-power of the timer granularity, a encoder can use a bit shift operation.

| design \ granularity | 1us | 2<sup>n</sup> us | 10<sup>n</sup> us |
|no scaling|noop|bit-shift|multiply|
|bit-shift|bit-shift|bit-shift|becomes inaccurate|

For the decoder side, it's noop vs. shift vs. multiply.

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