Subject: allowed to exceed max_ack_delay?

From: Martin Duke <[email-masked]>
Date: Wed, 20 Mar 2019 13:27:01 -0700

Section 13.1.1 states:
"The receiver's delayed acknowledgment timer SHOULD NOT exceed the current
RTT estimate or the value it indicates in the max_ack_delay transport
parameter."

Do we intend to allow exceeding max_ack_delay? Should it be a MUST NOT?

---

From: Ian Swett <[email-masked]>
Date: Wed, 20 Mar 2019 16:36:04 -0400

Now that we limit the ack_delay to max_ack_delay, we could make this a MUST
NOT, but I can't come up with a strong motivation for doing so.

On Wed, Mar 20, 2019 at 4:27 PM Martin Duke <[email-masked]> wrote:

> Section 13.1.1 states:
> "The receiver's delayed acknowledgment timer SHOULD NOT exceed the
> current RTT estimate or the value it indicates in the max_ack_delay transport
> parameter."
>

---

From: Nick Banks <[email-masked]>
Date: Wed, 20 Mar 2019 20:40:01 +0000

What if the peer was unable to response (because of CPU load, for instance) within the max_ack_delay? I don’t think this should be a MUST NOT, which implies to me that if broken it’s a fatal error to the connection.

- Nick

From: QUIC <[email-masked]> On Behalf Of Ian Swett
Sent: Wednesday, March 20, 2019 1:36 PM
To: Martin Duke <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: allowed to exceed max_ack_delay?

Now that we limit the ack_delay to max_ack_delay, we could make this a MUST NOT, but I can't come up with a strong motivation for doing so.

On Wed, Mar 20, 2019 at 4:27 PM Martin Duke <[email-masked]<mailto:[email-masked]>> wrote:
Section 13.1.1 states:
"The receiver's delayed acknowledgment timer SHOULD NOT exceed the current RTT estimate or the value it indicates in the max_ack_delay transport parameter."

---

From: Roberto Peon <[email-masked]>
Date: Wed, 20 Mar 2019 20:41:38 +0000

No way to enforce it deterministically, or to know that the peer is doing it improperly in the face of network delays, thus it probably should remain a SHOULD NOT.

-=R

From: QUIC <[email-masked]> on behalf of Ian Swett <ianswett=[email-masked]>
Date: Wednesday, March 20, 2019 at 1:36 PM
To: Martin Duke <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: allowed to exceed max_ack_delay?

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 20 Mar 2019 16:41:54 -0400

No, not unless it could somehow break things fundamentally.

Connections could be suspended on VM’s, suffer timer jumps, or just get
down prioritized on CPU. There is no need to break things here. To enforce
it, the peer would have to go out of its way tracking packet number
orderings.

It would be nice to state what could happen if the max is exceeded, and why
there is a max (haven’t read this section recently, so it might already be
there).

On 20 March 2019 at 21.36.33, Ian Swett (
ianswett=[email-masked]) wrote:

---

From: Ian Swett <[email-masked]>
Date: Wed, 20 Mar 2019 16:45:08 -0400

There's already text on what to do if it exceeds the max_ack_delay(cap it
to max_ack_delay) and I proposed some extra text to explain why in PR #2506
<https://github.com/quicwg/base-drafts/pull/2506>

On Wed, Mar 20, 2019 at 4:42 PM Mikkel Fahnøe Jørgensen <[email-masked]>
wrote:

> It would be nice to state what could happen if the max is exceeded, and
> why there is a max (haven’t read this section recently, so it might already
> be there).
>
> ianswett=[email-masked]
> <ianswett=[email-masked]>) wrote:
>
> Now that we limit the ack_delay to max_ack_delay, we could make this a
> MUST NOT, but I can't come up with a strong motivation for doing so.
>