Subject: Re: [quicwg/base-drafts] Merge crypto timeout into PTO (#2655)

From: Jana Iyengar <[email-masked]>
Date: Fri, 10 May 2019 18:01:10 -0700

janaiyengar commented on this pull request.

Sorry about the number of comments. This is unfortunate because most of the text is just moving about. My suggestion still stands -- merge this and we can fix the pending issues in subsequent PRs (which I'm happy to work on immediately after this lands).

> @@ -687,6 +620,69 @@ be acknowledged or declared lost.  Initial secrets however might be destroyed
 sooner, as soon as handshake keys are available (see Section 4.10 of
 {{QUIC-TLS}}).
 
+## PTO for Crypto Packets
+
+The initial PTO SHOULD be set to twice the initial RTT or 1 second if no
+initial RTT is available as recommended in {{?RFC6298}}.
+
+Until the server has validated the client's address on the path, the amount of
+data it can send is limited, as specified in Section 8.1 of {{QUIC-TRANSPORT}}.
+If not all unacknowledged CRYPTO data can be sent, then all unacknowledged
+CRYPTO data sent in Initial packets should be retransmitted.  If no data can be
+sent, then no alarm should be armed until data has been received from the

```suggestion
sent, then no alarm is needed for loss detection or recovery until data has been received from the
```

> @@ -1217,12 +1213,6 @@ SetLossDetectionTimer():
       time_of_last_sent_crypto_packet + timeout)
     return
 
-  // Don't arm timer if there are no ack-eliciting packets
-  // in flight.
-  if (no ack-eliciting packets in flight):
-    loss_detection_timer.cancel()
-    return
-

Revert this change. Why does this check need to be removed?

> @@ -687,6 +620,69 @@ be acknowledged or declared lost.  Initial secrets however might be destroyed
 sooner, as soon as handshake keys are available (see Section 4.10 of
 {{QUIC-TLS}}).
 
+## PTO for Crypto Packets
+
+The initial PTO SHOULD be set to twice the initial RTT or 1 second if no
+initial RTT is available as recommended in {{?RFC6298}}.
+
+Until the server has validated the client's address on the path, the amount of
+data it can send is limited, as specified in Section 8.1 of {{QUIC-TRANSPORT}}.
+If not all unacknowledged CRYPTO data can be sent, then all unacknowledged
+CRYPTO data sent in Initial packets should be retransmitted.  If no data can be
+sent, then no alarm should be armed until data has been received from the
+client.
+
+Because the server could be blocked until more packets are received, the client
+MUST ensure that the crypto retransmission timer is set if there is

```suggestion
MUST ensure that the PTO timer is set if there is
```

> +## PTO for Crypto Packets
+
+The initial PTO SHOULD be set to twice the initial RTT or 1 second if no
+initial RTT is available as recommended in {{?RFC6298}}.
+
+Until the server has validated the client's address on the path, the amount of
+data it can send is limited, as specified in Section 8.1 of {{QUIC-TRANSPORT}}.
+If not all unacknowledged CRYPTO data can be sent, then all unacknowledged
+CRYPTO data sent in Initial packets should be retransmitted.  If no data can be
+sent, then no alarm should be armed until data has been received from the
+client.
+
+Because the server could be blocked until more packets are received, the client
+MUST ensure that the crypto retransmission timer is set if there is
+unacknowledged crypto data or if the client does not yet have 1-RTT keys.
+If the crypto retransmission timer expires before the client has 1-RTT keys,

```suggestion
If the PTO timer expires before the client has 1-RTT keys,
```

>    if (has unacknowledged crypto data
       || endpoint is client without 1-RTT keys):
-    // Crypto retransmission timer.
+      // Crypto retransmission deadlock timer.

```suggestion
      // Initial PTO.
```

> @@ -1203,10 +1199,10 @@ SetLossDetectionTimer():
     // Time threshold loss detection.
     loss_detection_timer.update(loss_time)
     return
-
+    
   if (has unacknowledged crypto data

I think this if condition can go.

-- 
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/2655#pullrequestreview-236354682

---

From: Martin Thomson <[email-masked]>
Date: Sun, 12 May 2019 16:45:10 -0700

martinthomson commented on this pull request.

+## Retry and Version Negotiation
+
+A Retry or Version Negotiation packet causes a client to send another Initial
+packet, effectively restarting the connection process and resetting congestion
+control and loss recovery state, including resetting any pending timers.  Either
+packet indicates that the Initial was received but not processed.  Neither
+packet can be treated as an acknowledgment for the Initial.
+
+The client MAY however compute an RTT estimate to the server as the time period
+from when the first Initial was sent to when a Retry or a Version Negotiation
+packet is received.  The client MAY use this value to seed the RTT estimator for
+a subsequent connection attempt to the server.
+
+
+## Discarding Keys and Packet State {#discarding-packets}

Does this really belong under a section titled "Probe 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/pull/2655#pullrequestreview-236442550

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 13 May 2019 12:59:10 -0700

Agreed, this section should be promoted.

-- 
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/2655#discussion_r283510812