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

[ianswett <[e-mail]>]

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.

> @@ -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,

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