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

[ianswett <[e-mail]>]

ianswett commented on this pull request.

Looking much better.

>  
-A packet sent at the tail is particularly vulnerable to slow loss detection,
-since acks of subsequent packets are needed to trigger ack-based detection. To
-ameliorate this weakness of tail packets, the sender schedules a timer when the
-last ack-eliciting packet before quiescence is transmitted. Upon timeout,
-a Tail Loss Probe (TLP) packet is sent to evoke an acknowledgement from the
-receiver.
+A Probe Timeout (PTO) triggers a probe packet when ack-eliciting data is in
+flight but an acknowledgement is not received within the expected period of
+time.  A PTO enables a connection to recover from loss of tail packets or acks,
+where acks of subsequent packets are not available to trigger ack-based loss

This sentence is long and the second half is awkward.  I'd either split it into two sentences or just drop the second half.

>  
-To reduce latency, it is RECOMMENDED that the sender set and allow the TLP timer
-to fire twice before setting an RTO timer. In other words, when the TLP timer
-expires the first time, a TLP packet is sent, and it is RECOMMENDED that the TLP
-timer be scheduled for a second time. When the TLP timer expires the second
-time, a second TLP packet is sent, and an RTO timer SHOULD be scheduled {{rto}}.
+There is no requirement on the clock granularity. The PTO value MUST be set to

I find it weird you talk about not having a requirement on clock granularity, but don't discuss what it is more than the name.

Also, is this clock granularity or alarm granularity?  I think you want alarm granularity?

>  
-* When the final TLP packet is sent, the RTO period is set to max(SRTT +
-  4*RTTVAR + MaxAckDelay, kMinRTOTimeout)
+Consecutive PTO periods increase exponentially, and as a result, connection
+recovery latency increases exponentially as packets continue to be dropped in
+the network.  Sending two packets on PTO expiration increases resilience to
+packet drop in both directions, thus reducing the probability of consecutive PTO

How does it help in both directions?  If the two packets are sent at about the same time, wouldn't they be acknowledged in a single ACK?  I guess that depends upon the details of what "immediately" means for ACKs with newly missing packets?

>  
-* 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.  A probe packet MAY carry retransmitted unacknowledged
+data when new data is unavailable, when flow control does not permit new data to
+be sent, or to opportunistically reduce loss recovery delay.  Implementers MAY
+use alternate strategies for determining the content of probe packets, including
+sending new or retransmitted data based on the application's priorities.

Thanks, this is much better!

>  
-QUIC also diverges from TCP by including MaxAckDelay in the RTO period. Since
-QUIC corrects for this delay in its SRTT and RTTVAR computations, it is
-necessary to add this delay explicitly in the TLP and RTO computation.
+Delivery or loss of packets in flight is established when an acknowledgement is

Should this be "an ACK"?  We typically talk about an acknowledgement as referencing a single packet.

>  
-QUIC also diverges from TCP by including MaxAckDelay in the RTO period. Since
-QUIC corrects for this delay in its SRTT and RTTVAR computations, it is
-necessary to add this delay explicitly in the TLP and RTO computation.
+Delivery or loss of packets in flight is established when an acknowledgement is
+received that newly acknowledges one or more packets.  An endpoint might receive
+an acknowledgement after multiple consecutive PTO periods.

I feel like you're trying to say something more with this last sentence, but I'm not sure what?

> @@ -802,7 +772,7 @@ Pseudocode for SetLossDetectionTimer follows:
         timeout = 2 * kInitialRtt
       else:
         timeout = 2 * smoothed_rtt
-      timeout = max(timeout, kMinTLPTimeout)
+      timeout = max(timeout, granularity)

```suggestion
      timeout = max(timeout, kGranularity)
```

>      timeout =
       smoothed_rtt + 4 * rttvar + max_ack_delay
-    timeout = max(timeout, kMinRTOTimeout)
-    timeout = timeout * (2 ^ rto_count)
-    if (tlp_count < kMaxTLPs):
-      // Tail Loss Probe
-      tlp_timeout = max(1.5 * smoothed_rtt
-                        + max_ack_delay, kMinTLPTimeout)
-      timeout = min(tlp_timeout, timeout)
+    timeout = max(timeout, granularity)

```suggestion
    timeout = max(timeout, kGranularity)
```

-- 
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#pullrequestreview-183994915