Subject: Re: [quicwg/base-drafts] PTO MUST send new data or retransmit data if possible (#3057)

From: Jana Iyengar <[email-masked]>
Date: Thu, 17 Oct 2019 11:07:13 -0700

janaiyengar commented on this pull request.

> @@ -526,15 +524,17 @@ as a probe, unless there is no data available to send.  An endpoint MAY send up
 to two full-sized datagrams containing ack-eliciting packets, to avoid an
 expensive consecutive PTO expiration due to a single lost datagram.
 
-It is possible that the sender has no new or previously-sent data to send.  As
-an example, consider the following sequence of events: new application data is
-sent in a STREAM frame, deemed lost, then retransmitted in a new packet, and
-then the original transmission is acknowledged.  In the absence of any new
-application data, a PTO timer expiration now would find the sender with no new
-or previously-sent data to send.
-
-When there is no data to send, the sender SHOULD send a PING or other
-ack-eliciting frame in a single packet, re-arming the PTO timer.
+When the PTO timer expires, and there is new or previously sent unacknowledged
+data, it MUST be sent.  Data at Initial encryption MUST be sent before

```suggestion
data, it MUST be sent.  Data that was previously sent with Initial encryption MUST be sent before
```

> @@ -526,15 +524,17 @@ as a probe, unless there is no data available to send.  An endpoint MAY send up
 to two full-sized datagrams containing ack-eliciting packets, to avoid an
 expensive consecutive PTO expiration due to a single lost datagram.
 
-It is possible that the sender has no new or previously-sent data to send.  As
-an example, consider the following sequence of events: new application data is
-sent in a STREAM frame, deemed lost, then retransmitted in a new packet, and
-then the original transmission is acknowledged.  In the absence of any new
-application data, a PTO timer expiration now would find the sender with no new
-or previously-sent data to send.
-
-When there is no data to send, the sender SHOULD send a PING or other
-ack-eliciting frame in a single packet, re-arming the PTO timer.
+When the PTO timer expires, and there is new or previously sent unacknowledged
+data, it MUST be sent.  Data at Initial encryption MUST be sent before
+Handshake data and data at Handshake encryption MUST be sent before any

```suggestion
Handshake data and, similarly, data previously sent at Handshake encryption MUST be sent before any
```

> @@ -495,11 +495,9 @@ 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}}.
-Data at Initial encryption MUST be retransmitted before Handshake data and
-data at Handshake encryption MUST be retransmitted before any ApplicationData
-data.  If no data can be sent, then the PTO alarm MUST NOT be armed until
-data has been received from the client.
+data it can send is limited to three times the amount of data received,
+as specified in Section 8.1 of {{QUIC-TRANSPORT}}. If no data can be sent,

You want to allow PINGs. "... and no other ack-eliciting packet is sent".

-When there is no data to send, the sender SHOULD send a PING or other
-ack-eliciting frame in a single packet, re-arming the PTO timer.
+It is possible the sender has no new or previously-sent data to send.
+As an example, consider the following sequence of events: new application data
+is sent in a STREAM frame, deemed lost, then retransmitted in a new packet,
+and then the original transmission is acknowledged.  When there is no data to
+send, the sender SHOULD send a PING or other ack-eliciting frame in a single
+packet, re-arming the PTO timer.

So the problem this was intended to address was exactly that accounting discrepancy. There are two ways to handle outstanding packets if we want to give up on them: call them lost and reduce the window (see text below, maybe that should be part of this paragraph), or send a PING to elicit an ACK from the receiver. The text used to recommend the calling them lost IIRC, but I don't see a clear winner here.

-- 
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/3057#pullrequestreview-302192947

---

From: ianswett <[email-masked]>
Date: Thu, 24 Oct 2019 14:52:29 -0700

@ianswett pushed 1 commit.

3662405decdc750cb97d7b1bd3eab1ad62abc0ff  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/3057/files/0236874f3a51eb4166b9070a21f1acd8dae432b1..3662405decdc750cb97d7b1bd3eab1ad62abc0ff

---

From: ianswett <[email-masked]>
Date: Thu, 24 Oct 2019 14:52:51 -0700

6a225b8bfc8b8aad98fa0ffee512f59940db48b5  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/3057/files/3662405decdc750cb97d7b1bd3eab1ad62abc0ff..6a225b8bfc8b8aad98fa0ffee512f59940db48b5

---

From: ianswett <[email-masked]>
Date: Thu, 24 Oct 2019 14:53:45 -0700

886db2af9e5c70a553dcf1d71d34fbe75c963a2d  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/3057/files/6a225b8bfc8b8aad98fa0ffee512f59940db48b5..886db2af9e5c70a553dcf1d71d34fbe75c963a2d

---

From: ianswett <[email-masked]>
Date: Thu, 24 Oct 2019 14:56:04 -0700

ianswett commented on this pull request.

Thanks for your comments @janaiyengar.  One follow-up question about whether we should always arm the PTO even if the amplification factor has been hit on the server side?  That does have the benefit of forcing the client to send a padded Initial ACK-only packet.

Are you suggesting we always arm the PTO and if we've hit the amplification factor, the server should send a PING-only packet?  That actually sounds easier than not arming it and prompts the client to send a padded Initial ACK, but I'm not sure if that's what you're suggesting?

-- 
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/3057#pullrequestreview-306885812

---

From: martinduke <[email-masked]>
Date: Mon, 28 Oct 2019 10:31:17 -0700

martinduke commented on this pull request.

What is the purpose of this statement?

> Data that was previously sent with Initial encryption
> MUST be sent before Handshake data and data previously sent at Handshake
> MUST be sent before any ApplicationData data.

Doesn't this conflict with the "PTO per packet number space" PR? If I'm implementing that PR most literally, I should PTO only the data from the space that expired. For example, I can have the 0RTT/1RTT PTO timer running first with some handshake data also in flight, and I should send just 0RTT/1RTT.

If I'm coalescing, I'm not sure why this would matter.

As for "MUST send new/unacked data", is that necessary? Why is not OK to send a PING instead to reduce bytes in flight? Perhaps I'm expecting new data soon and want to preserve the window space? I'd prefer if this were a SHOULD.

-- 
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/3057#discussion_r339696919

---

From: ianswett <[email-masked]>
Date: Mon, 28 Oct 2019 11:08:28 -0700

I created https://github.com/quicwg/base-drafts/issues/3161 to discuss whether we want to make a design change here, FWIW.

-- 
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/3057#discussion_r339715332

---

From: ianswett <[email-masked]>
Date: Mon, 28 Oct 2019 11:33:02 -0700

Yes, but this is existing text and I didn't want to tie this PR to the PTO per PN space PR.

One of the reasons I'd like to get this change in soon is it's going to cause conflicts with the multiple PN spaces PR, and the other PR is more substantive.

The original issue(#3056) was that there was no MUST to retransmit the client Initial, and if the server doesn't create connection state until receiving a client Initial, the handshake fails.

That being said, the client sending a full sized ack eliciting packet that's not the Initial seems odd.  And if the server isn't going to create state, it seems like it should send a Retry to do path validation.

-- 
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/3057#discussion_r339726721

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 29 Oct 2019 18:50:39 -0700

Thanks for opening other issues, @ianswett. I'm going to merge this, since I think it's a net betterment over what we have. We can continue the other discussions on the other issues/PRs.

-- 
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/3057#issuecomment-547703832

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 29 Oct 2019 18:50:53 -0700

janaiyengar approved this pull request.

-- 
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/3057#pullrequestreview-308926932

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 29 Oct 2019 18:51:13 -0700

Merged #3057 into master.

-- 
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/3057#event-2754366898