Re: [quicwg/base-drafts] Simplify TLP and RTO into Probe Timeout (#2114)

[janaiyengar <[e-mail]>]

janaiyengar commented on this pull request.



>  
-A PTO value of at least 1.5*SRTT ensures that the ACK is overdue.  The 1.5 is
-based on {{?TLP}}, but implementations MAY experiment with other constants.
+The PTO period is the amount of time that a sender ought to wait for an

This isn't a normative statement. I can use should, but SHOULD isn't warranted here.

>  
-A TLP packet SHOULD carry new data when possible. If new data is unavailable or
-new data cannot be sent due to flow control, a TLP packet MAY retransmit
-unacknowledged data to potentially reduce recovery time. Since a TLP timer is
-used to send a probe into the network prior to establishing any packet loss,
-prior unacknowledged packets SHOULD NOT be marked as lost when a TLP timer
-expires.
+A PTO timer is set on an ack-eliciting tail packet.  A sender may not know that

I don't understand your suggestion, but I've rewritten this, PTAL

>  
-* When an RTO timer expires, the RTO period is doubled.
+Probe packets sent on a PTO MUST be ack-eliciting.  A probe packet SHOULD carry
+new data when possible.  Implementers MAY use alternate strategies for
+determining the content of probe packets.  An implementation could use new data

I've rephrased it. The idea is to recommend one strategy but allow experimentation.

>  
-A packet sent on an RTO timer MUST NOT be blocked by the sender's congestion
-controller. A sender MUST however count these packets as being in flight, since
-this packet adds network load without establishing packet loss.
+If an ACK frame is received that newly acknowledges only those packets that were
+sent after a PTO timer expiration, all unacknowledged packets with lower packet
+numbers MUST be marked as lost.

This is what we had earlier, I'm just keeping this text. I think we should simplify this response to a single loss-detection response, but I'd like to do that next.

> @@ -577,21 +560,18 @@ kTimeThreshold:
   considers a packet lost. Specified as an RTT multiplier. The RECOMMENDED
   value is 9/8.
 
-kMinTLPTimeout:
-: Minimum time in the future a tail loss probe timer may be set for.
-  The RECOMMENDED value is 10ms.
+kGranularity:

This is what we used to do with kMinTLP and kMinRTO. There's a forward reference where it's used earlier to this section.

>  
-Acknowledgement or loss of tail loss probes are treated like any other packet.
+Probe packets MUST NOT be blocked by the congestion controller.  A sender MUST
+however count these packets as being additionally in flight, since these packets
+adds network load without establishing packet loss.  Note that sending probe
+packets might cause the sender's estimated bytes in flight to exceed the

I don't like this use of bytes in flight... it doesn't sound right. If "bytes in flight" is being used as a var name, we should hyphenate and use it. Otherwise, as an English sentence, it doesn't read well. I'll change it because I think we need to make this change more globally in this doc.

>  
-Acknowledgement or loss of tail loss probes are treated like any other packet.
+Probe packets MUST NOT be blocked by the congestion controller.  A sender MUST
+however count these packets as being additionally in flight, since these packets
+adds network load without establishing packet loss.  Note that sending probe
+packets might cause the sender's estimated bytes in flight to exceed the
+sender's congestion window until an acknowledgement is received that establishes

I prefer "established as lost" to "packets are lost".  Packets are lost when they're dropped in the network, and the sender establishes loss later.

>  
-## Retransmission Timeout
+A PTO expiration is classified as spurious or valid when an ACK frame is
+received that newly acknowledges packets in flight, see {{pto-loss}}.  On a
+valid PTO, the congestion window MUST be reduced to the minimum congestion
+window and slow start is re-entered.

Only if there was in fact loss previously and if the PTO is valid. If the PTO is spurious, which is equivalent to when TLP is triggered but is spurious, the outcome is the same -- no action.

-- 
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/2114#discussion_r240817198