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

[Jana Iyengar <[e-mail]>]

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