Subject: [quicwg/base-drafts] Merge Crypto timeout and PTO (#2806)

From: ianswett <[email-masked]>
Date: Tue, 18 Jun 2019 19:51:58 -0700

Another attempt at #2655 

Fixes #2650, Fixes #2648
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Update draft-ietf-quic-recovery.md

-- File Changes --

    M draft-ietf-quic-recovery.md (110)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2806.patch
https://github.com/quicwg/base-drafts/pull/2806.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/2806

---

From: ianswett <[email-masked]>
Date: Tue, 18 Jun 2019 19:52:58 -0700

@ianswett pushed 1 commit.

98fbe4a17920997910f9a394749d15f2c82e25f1  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2806/files/3580c61d8ed6343e332fffd5feddddb12fa97780..98fbe4a17920997910f9a394749d15f2c82e25f1

---

From: ianswett <[email-masked]>
Date: Tue, 18 Jun 2019 20:05:56 -0700

fa3b5497e8019ce105433a216867dd098c365ad7  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2806/files/98fbe4a17920997910f9a394749d15f2c82e25f1..fa3b5497e8019ce105433a216867dd098c365ad7

---

From: MikkelFJ <[email-masked]>
Date: Wed, 19 Jun 2019 01:07:40 -0700

mikkelfj commented on this pull request.

> +set to twice the initial RTT.
+
+Resumed connections over the same network SHOULD use the previous connection's
+final smoothed RTT value as the resumed connection's initial RTT.  If no
+previous RTT is available, or if the network changes, the initial RTT SHOULD
+be set to 500ms, resulting in a 1 second initial timeout as recommended in
+{{?RFC6298}}.
+
+A connection MAY use the delay between sending a PATH_CHALLENGE and receiving
+a PATH_RESPONSE to seed initial_rtt for a new path, but the delay SHOULD NOT
+be considered an RTT sample.
+
+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

```suggestion
CRYPTO data sent in Initial packets should be retransmitted if possible.  If no data can be
```

> +Resumed connections over the same network SHOULD use the previous connection's
+final smoothed RTT value as the resumed connection's initial RTT.  If no
+previous RTT is available, or if the network changes, the initial RTT SHOULD
+be set to 500ms, resulting in a 1 second initial timeout as recommended in
+{{?RFC6298}}.
+
+A connection MAY use the delay between sending a PATH_CHALLENGE and receiving
+a PATH_RESPONSE to seed initial_rtt for a new path, but the delay SHOULD NOT
+be considered an RTT sample.
+
+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.

How about idle timeout / connection abort?

-- 
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/2806#pullrequestreview-251533231

---

From: Marten Seemann <[email-masked]>
Date: Wed, 19 Jun 2019 01:09:55 -0700

marten-seemann commented on this pull request.

The idle timeout is a transport concept, it has nothing to do with loss recovery.

-- 
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/2806#discussion_r295170421

---

From: MikkelFJ <[email-masked]>
Date: Wed, 19 Jun 2019 01:14:20 -0700

Maybe say "no recovery alarm" or "no retransmission alarm"

-- 
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/2806#discussion_r295172150

---

From: Matt Olson <[email-masked]>
Date: Wed, 19 Jun 2019 15:51:00 -0700

maolson-msft commented on this pull request.

> @@ -616,6 +553,50 @@ sender might choose to optimize this by setting the timer fewer times if it
 knows that more ack-eliciting packets will be sent within a short period of
 time.
 
+The retransmission timer is not set if the time threshold

```suggestion
The probe timer is not set if the time threshold
```

-- 
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/2806#pullrequestreview-252009891

---

From: Matt Olson <[email-masked]>
Date: Wed, 19 Jun 2019 15:53:13 -0700

+A connection MAY use the delay between sending a PATH_CHALLENGE and receiving
+a PATH_RESPONSE to seed initial_rtt for a new path, but the delay SHOULD NOT
+be considered an RTT sample.
+
+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 retransmission timer is set if there is
+unacknowledged crypto data or if the client does not yet have 1-RTT keys.
+If the retransmission timer expires before the client has 1-RTT keys,

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

-- 
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/2806#pullrequestreview-252010535