Subject: [quicwg/base-drafts] max_ack_delay is unknown when a new connection is established (#2638)

From: Marten Seemann <[email-masked]>
Date: Sun, 21 Apr 2019 21:03:52 -0700

The max_ack_delay is advertised in the transport parameters.
The recovery text assumes that this value is available right from the beginning of a connection.

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

---

From: ianswett <[email-masked]>
Date: Mon, 22 Apr 2019 06:02:57 -0700

I thought this sentence indicated it was 25ms until a value is received: "The maximum ack delay is communicated in the "max_ack_delay" transport parameter and the default value is 25ms.", but I agree it could be clearer, ie: "and the default value and the value prior to receiving the transport parameters is 25ms."?

As a related point, I think it turns out the max_ack_delay doesn't come into play until the transport params are available, because "crypto packets SHOULD use a very short ack delay, such as the local timer granularity."
https://tools.ietf.org/html/draft-ietf-quic-recovery-19#section-4.1

-- 
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/2638#issuecomment-485412724

---

From: Marten Seemann <[email-masked]>
Date: Mon, 22 Apr 2019 23:57:09 +0000 (UTC)

It's not used for sending, but we're using it when calculating the RTT.

-- 
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/2638#issuecomment-485592650

---

From: ianswett <[email-masked]>
Date: Mon, 22 Apr 2019 17:12:42 -0700

Hmm, maybe we should default it to 0 before it's been received then?

Or should we just specify it's 25ms until transport params have been received?

-- 
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/2638#issuecomment-485595502

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 22 Apr 2019 17:31:31 -0700

I'd argue that we should use 0 until receiving TP.

We require endpoints to send ACKs for crypto packets immediately. That means that the ack-delay value found in the ACK packet is something that the peer could not control. It is my understanding that we consider these uncontrollable delays induced within an endpoint as part of RTT.

-- 
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/2638#issuecomment-485598593

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 24 Apr 2019 01:33:34 -0700

@marten-seemann : It's not about the RTT, it's about the PTO, or crypto timeout to be more precise. It's reasonable to continue using max_ack_delay for RTT computations, since it caps ack_delay (ack_delay should be 0 or something very small for those anyways). But when computing the crypto timeout, we don't want to include the max_ack_delay for the reasons you cite.

The draft currently does not have the max_ack_delay being used for the crypto retransmission timer, which was an oversight.  We'll clean that up separately, but fortuitously, this means that there's no max_ack_delay in the pseudo_code or text to change.

I don't mind initializing it to 0 or any value, but it won't have any real effect on endpoint behavior based on the draft.  max_ack_delay doesn't kick in until after the handshake is roughly complete.

-- 
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/2638#issuecomment-486124580

---

From: ianswett <[email-masked]>
Date: Wed, 24 Apr 2019 07:01:38 -0700

The crypto retransmission timer doesn't use max_ack_delay intentionally, see: https://tools.ietf.org/html/draft-ietf-quic-recovery-20#section-4.1

 "In order to quickly complete the handshake and avoid spurious
   retransmissions due to crypto retransmission timeouts, crypto packets
   SHOULD use a very short ack delay, such as the local timer
   granularity.  ACK frames SHOULD be sent immediately when the crypto
   stack indicates all data for that packet number space has been
   received.

-- 
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/2638#issuecomment-486245724

---

From: MikkelFJ <[email-masked]>
Date: Sat, 27 Apr 2019 23:22:11 -0700

Same applies to `ack_delay_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/issues/2638#issuecomment-487348709

---

From: Marten Seemann <[email-masked]>
Date: Sun, 28 Apr 2019 00:07:58 -0700

@mikkelfj 

Which why the spec says the following:
> The default value is also used for ACK frames that are sent in Initial and Handshake packets.

-- 
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/2638#issuecomment-487351648