Subject: [quicwg/base-drafts] What the maximum of TransportParameters.max_ack_delay? (#2282)

From: Kazuho Oku <[email-masked]>
Date: Tue, 01 Jan 2019 13:38:51 -0800

Previously, the maximum was 255 milliseconds, because it was a 8-bit value. But now that the type is varint, the value can express up to 2<sup>62</sup> - 1 milliseconds.

Should we define a reasonable maximum for the value, like what we have for ack_delay_exponent? Capping it so somewhere well below 32-bit range makes sense to me.

I ask this in fear that QUIC stacks might ship with code that fails to handle unreasonably large values.

-- 
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/2282

---

From: ianswett <[email-masked]>
Date: Tue, 01 Jan 2019 18:45:42 -0800

Capping it to max signed int SGTM.

-- 
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/2282#issuecomment-450778710

---

From: Martin Thomson <[email-masked]>
Date: Tue, 01 Jan 2019 19:07:09 -0800

How big?  2^16-1, 2^32-1, 2^64-1, 2^30-1?  I'd have said that 2^14-1 would be more than enough here.  16 seconds is a long time to hold an ACK.

-- 
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/2282#issuecomment-450780171

---

From: MikkelFJ <[email-masked]>
Date: Wed, 02 Jan 2019 02:00:38 -0800

Is there an attack here? Otherwise why bother - its just one more complexity.

-- 
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/2282#issuecomment-450824301

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 02 Jan 2019 13:23:18 -0800

> Is there an attack here?

A bug sometimes ends up as an vulnerability on the server-side, because many connections are served by one process.

I won't be surprised if some QUIC server using 32-bit millisecond-precision timer crashes while talking with a client that specifies an ACK delay of 2<sup>32</sup>-alpha, because that would likely generate a negative timeout.

-- 
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/2282#issuecomment-450989326

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 02 Jan 2019 21:30:49 +0000 (UTC)

> How big? 2^16-1, 2^32-1, 2^64-1, 2^30-1? I'd have said that 2^14-1 would be more than enough here. 16 seconds is a long time to hold an ACK.

2<sup>32</sup>-1 would be a bit too big for 32-bit timers. OTOH I do not think anybody will be using a 16-bit millisecond-precision timer and therefore 2<sup>14</sup>-1 or  2<sup>16</sup>-1 sounds fine.

-- 
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/2282#issuecomment-450991267

---

From: ianswett <[email-masked]>
Date: Thu, 03 Jan 2019 10:26:15 -0800

I'm concerned about int overflow and other implementation bugs.

2^14-1 SGTM

-- 
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/2282#issuecomment-451232855

---

From: janaiyengar <[email-masked]>
Date: Thu, 03 Jan 2019 17:15:03 -0800

2^14-1 is good.

Interplanetary QUIC can be pushed to v2.

On Thu, Jan 3, 2019 at 10:26 AM ianswett <[email-masked]> wrote:

> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/2282#issuecomment-451232855>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AKjg1KCWbFuVUhVT2lWAzoBWQgyN_Dwyks5u_ktGgaJpZM4ZmCfD>
> .
>

-- 
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/2282#issuecomment-451329064

---

From: MikkelFJ <[email-masked]>
Date: Fri, 04 Jan 2019 01:22:20 -0800

> Interplanetary QUIC can be pushed to v2.

Thanks for making my point.

How about low power devices that are prone to falling asleep?

-- 
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/2282#issuecomment-451393066

---

From: janaiyengar <[email-masked]>
Date: Fri, 04 Jan 2019 16:05:43 -0800

Do they take > 16 seconds to wake up?

-- 
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/2282#issuecomment-451605615

---

From: ianswett <[email-masked]>
Date: Fri, 04 Jan 2019 16:51:52 -0800

Equally importantly, would they ever want to indicate a 16 second ack delay, given the latency implications in the current recovery algorithms?

-- 
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/2282#issuecomment-451611687

---

From: MikkelFJ <[email-masked]>
Date: Sat, 05 Jan 2019 05:29:16 -0800

> Do they take > 16 seconds to wake up?

I don't think so, but if we settle on a low value, it is worth keeping in 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/2282#issuecomment-451655361

---

From: MikkelFJ <[email-masked]>
Date: Sat, 05 Jan 2019 05:50:12 -0800

Actually NarrowBand-IoT is just about to be deployed on the danish mobil net, and from what I understand sensor latency is between 1-10s, but I don't know how that translates into network packet processing.

https://en.wikipedia.org/wiki/Narrowband_IoT

-- 
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/2282#issuecomment-451656759

---

From: Martin Thomson <[email-masked]>
Date: Mon, 07 Jan 2019 21:21:27 -0800

Closed #2282 via #2301.

-- 
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/2282#event-2059283688