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

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Jul 2019 00:10:39 -0700

I'm very much inclined to propose a vote (i.e., to invoke [RFC 3929](https://tools.ietf.org/html/rfc3929)) on this one in Montreal.  I get the *strong* impression that no one really cares about this that much.

Would anyone object if I put up a slide with the three options up and we could all hum or wave hands at the ones we liked the least?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-509519263

---

From: Marten Seemann <[email-masked]>
Date: Tue, 09 Jul 2019 00:59:39 -0700

@martinthomson I think that's a good idea, as long as we can summarize the pros and cons of each proposal before the vote.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-509534880

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Jul 2019 01:15:44 -0700

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).

Did I miss anything?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-509540201

---

From: ianswett <[email-masked]>
Date: Tue, 09 Jul 2019 10:13:38 -0700

I'm fine with a vote in Montreal, though I'd really prefer not to remove this entirely.  If there is not a clear favorite, then I'd suggest doing a hum for which option people dislike most and not doing that one?

That list covers everything that comes to mind.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-509728546

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 09 Jul 2019 16:53:28 -0700

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

@martinthomson 
> 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…

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|
|multiplier|bit-shift|bit-shift|bit-shift|

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:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-509852239

---

From: Martin Thomson <[email-masked]>
Date: Wed, 10 Jul 2019 00:18:48 -0700

Yeah, we have times expressed in nanoseconds, so we have to divide always.

I heard the "dislike most" suggestion; I was planning on that anyway.  I've heard a lot stronger negative sentiment related to the "remove the TP" option.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-509941376

---

From: Martin Thomson <[email-masked]>
Date: Wed, 10 Jul 2019 00:38:52 -0700

For those following along, here is a draft of some [slides for this process](https://docs.google.com/presentation/d/16j7fcFHcj-copP32BysJkiDt3XZ0mOmRrkG6kzJWYuQ/edit?usp=sharing).  Comments are open if you want to improve them in any way.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-509947313

---

From: MikkelFJ <[email-masked]>
Date: Wed, 10 Jul 2019 02:34:28 -0700

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:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-509988126

---

From: MikkelFJ <[email-masked]>
Date: Wed, 10 Jul 2019 02:37:10 -0700

It should be noted though, that 64-bit multiplication on a 32-bit, or smaller MCU, is comparatively slow. These will also suffer from GCM, but there is other crypto.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-509989213

---

From: Martin Thomson <[email-masked]>
Date: Wed, 10 Jul 2019 04:40:34 -0700

I'm fairly confident that these operations will be done on relatively small values, and so optimization to that degree will be possible.  I plan to use Rust u128 values and to ignore the cost, but I realize that not every implementation can afford to spend upwards of 4 CPU cycles on an operation that you perform once every other packet.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-510025883

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 22 Jul 2019 12:22:22 -0700

In general, if CPU is a problem, there's a simple fix. Ignore ack delay
entirely. Your RTT values will be higher, causing recovery to take longer,
but that is the tradeoff. At any rate, this recovery time won't be worse
than TCP, since TCP includes receiver delays in its RTT estimates.

On Wed, Jul 10, 2019 at 7:40 AM Martin Thomson <[email-masked]>
wrote:

> I'm fairly confident that these operations will be done on relatively
> small values, and so optimization to that degree will be possible. I plan
> to use Rust u128 values and to ignore the cost, but I realize that not
> every implementation can afford to spend upwards of 4 CPU cycles on an
> operation that you perform once every other packet.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/2670?email_source=notifications&email_token=ACUOBVFXENMDISDM33ZM5PDP6XDDDA5CNFSM4HLJKNXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZTGBGY#issuecomment-510025883>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ACUOBVBJWPWETAPZOLXDUSDP6XDDDANCNFSM4HLJKNXA>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-513919018

---

From: Lars Eggert <[email-masked]>
Date: Tue, 23 Jul 2019 07:32:53 -0700

Assigned to @martinthomson since he presented in Montreal.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-514236413

---

From: Lars Eggert <[email-masked]>
Date: Tue, 23 Jul 2019 07:54:47 -0700

Discussed in Montreal. Option B eventually got consensus in the room.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-514246172

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Jul 2019 10:52:16 -0700

The agreed option requires no action, so this is ready for a consensus call.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-515146732

---

From: MikkelFJ <[email-masked]>
Date: Thu, 25 Jul 2019 10:55:49 -0700

> The agreed option requires no action, so this is ready for a consensus call.

How so - isn't option B about a multiplier TP - that would require a PR no?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-515148389

---

From: Christian Huitema <[email-masked]>
Date: Thu, 25 Jul 2019 11:05:01 -0700

@mikkelfj The "option B" discussed during the WG meeting was to effectively keep the text as is.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-515152210

---

From: MikkelFJ <[email-masked]>
Date: Thu, 25 Jul 2019 11:06:23 -0700

OK, thanks.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2670#issuecomment-515152751