Subject: [quicwg/base-drafts] change the ack delay exponent to an ack delay multiplier (#2679)

From: Marten Seemann <[email-masked]>
Date: Wed, 08 May 2019 20:28:54 -0700

Since several people expressed interested in changing the `ack_delay_exponent` to a multiplier in #2670, I decided to write down a PR with that change.
We will probably have a discussion about the default value of this TP. For now, I chose 10 microseconds, which is close to the value we had so far.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2679

-- Commit Summary --

  * change the ack delay exponent to an ack delay multiplier

-- File Changes --

    M draft-ietf-quic-transport.md (29)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2679.patch
https://github.com/quicwg/base-drafts/pull/2679.diff

-- 
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/pull/2679

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 08 May 2019 21:21:07 -0700

kazuho approved this pull request.

-- 
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/pull/2679#pullrequestreview-235393365

---

From: Martin Thomson <[email-masked]>
Date: Wed, 08 May 2019 21:58:24 -0700

Let's pretend that this addresses/closes #2670.

-- 
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/pull/2679#issuecomment-490743685

---

From: Martin Thomson <[email-masked]>
Date: Wed, 08 May 2019 22:02:27 -0700

martinthomson commented on this pull request.

-: The ACK delay exponent is an integer value indicating an
-  exponent used to decode the ACK Delay field in the ACK frame ({{frame-ack}}).
-  If this value is absent, a default value of 3 is assumed (indicating a
-  multiplier of 8). Values above 20 are invalid.
+: The ACK delay multiplier is an integer value indicating a multiplier used to
+  decode the ACK Delay field in the ACK frame ({{frame-ack}}). If this value is
+  absent, a default value of 10 (corresponding to a resolution of 10
+  microseconds)is assumed. Values above 1,000,000 (corresponding to a resolution
+  of 1 second) are invalid.

It might be better to leave the multiplier at 1 rather than pick a value.

Also, I assume that we want to prohibit 0.

-- 
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/pull/2679#pullrequestreview-235399785

---

From: MikkelFJ <[email-masked]>
Date: Wed, 08 May 2019 22:38:30 -0700

Is this necessary? Imposing a multiplier on peer might be OK, but if we ever get to a situation where division is forced, an exponent is vastly better - so this concern is about precefence.

And I don’t really see what a multiplier gains over an exponent.

-- 
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/pull/2679#issuecomment-490750849

---

From: Marten Seemann <[email-masked]>
Date: Wed, 08 May 2019 22:42:03 -0700

@mikkelfj Where is a division necessary? The PR only requires multiplication.

-- 
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/pull/2679#issuecomment-490751503

---

From: Marten Seemann <[email-masked]>
Date: Wed, 08 May 2019 22:53:56 -0700

@marten-seemann pushed 1 commit.

23e29f8461a430d6e287c038b6fd6857f0478881  set default ack_delay_multiplier = 1, make 0 invalid

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2679/files/611511de25f154b2431d1c9977368deb9b1114ee..23e29f8461a430d6e287c038b6fd6857f0478881

---

From: MikkelFJ <[email-masked]>
Date: Wed, 08 May 2019 23:42:52 -0700

As I say, this sets a precedence if we need to do more scales in the future. In the current form the sender decides what division is necessary. So I think there should be strong win for multiplication to prefer that.

That said, it is already messy with base 10 units, but constant mult/div by 1000 is manageable.

Another complication is overflow detection. With an exponent you can easily construct a mask. With multiplication you must either add another max var, or have another multiplication to compute it on the fly. Otherwise this will probably be an attack vector on naive implementations.

-- 
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/pull/2679#issuecomment-490764779

---

From: Martin Thomson <[email-masked]>
Date: Thu, 09 May 2019 02:25:11 -0700

I don't think we need to worry about optimization of these corner cases.

-- 
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/pull/2679#issuecomment-490828622