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

[Benjamin Saunders <[e-mail]>]

Ralith commented on this pull request.

Will the larger PTO packets this produces (often MTU-sized instead of minimally-sized) adversely affect performance under heavy congestion?

Do we also need to add logic guiding the level at which a PTO is sent? Quinn currently always sends PTOs at the highest encryption level for which keys are known, which under the current logic would make loss of any part of the server's first flight unrecoverable.

> @@ -526,12 +526,11 @@ 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 the PTO timer expires, and there is new or previously sent data, it MUST
+be sent.  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.

This example only applies to implementations that can usefully process acknowledgements for packets they've already deemed lost and retransmitted the contents of, which I don't think is required. Is there a more common case?

-- 
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-291851055