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

MikkelFJ <> Wed, 10 July 2019 09:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 61F821200FA for <>; Wed, 10 Jul 2019 02:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Status: No, score=-6.596 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_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 suTEzWhElnIz for <>; Wed, 10 Jul 2019 02:34: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 04A12120099 for <>; Wed, 10 Jul 2019 02:34:29 -0700 (PDT)
Date: Wed, 10 Jul 2019 02:34:28 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1562751268; bh=Hi57iufC1vLIuCXmcBmrQVp3TAQ8FKd7sGtwnESYHeY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=VXnL9ErjKKjrHwzGNWtWkrWdQgsnL0F3Rb/+UHVdb/Z5yQlJ8n/OTmKD0XzlNPOVk QzoM3pvsgEeuQLYW0j3/80/XZFzz+Q69ILFu8I0E1qU/JxSpO5n4xZsJjcbfP7ykOW R2H66Cw9ldFSvILi3RWilX5o8dUH6Ya+UYsiemi8=
From: MikkelFJ <>
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_5d25b124424d7_b9b3fdb854cd95c7686ce"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
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, 10 Jul 2019 09:34:32 -0000

So I'm am one the few holding out for shift. I disagree with many of the arguments made on shift being imprecise, but I come to some of the same conclusion @kazuho has recently posted:

The encoded can choose its multiplier. It can choose one that it is a power of 2.

The native representation of time my require scaling anyway, so you might end up with a non-power of two. However, this is typically a constant, and division by a constant is multiplication if you do it compile time. It is a long multiplication which is slower, but not that much.

Therefore I am reverting on my stance and think that a multiplier is acceptable, as long as it can be chosen statically for the application, or it can choose a power of 2 dynamically.

More generally I still think it is a problem to guess the time scale and would like to have an adaptive scale without transport parameters, using 16 bit unsigned floats, but there is zero traction on that here.

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