Re: [quicwg/base-drafts] Ack Delay and TLP (#1796)

[Nick Banks <[e-mail]>]

nibanks commented on this pull request.



> @@ -834,8 +827,13 @@ Pseudocode for SetLossDetectionTimer follows:
       timeout = timeout * (2 ^ rto_count)
       if (tlp_count < kMaxTLPs):
         // Tail Loss Probe
-        tlp_timeout = max(1.5 * smoothed_rtt
-                           + max_ack_delay, kMinTLPTimeout)
+        if (bytes_in_flight < 2400):
+          // Less than one full-sized packet in flight.
+          tlp_timeout = max(1.5 * smoothed_rtt

Should the comment here be `Less than two full-sized packets in flight`?

> @@ -834,8 +827,13 @@ Pseudocode for SetLossDetectionTimer follows:
       timeout = timeout * (2 ^ rto_count)
       if (tlp_count < kMaxTLPs):
         // Tail Loss Probe
-        tlp_timeout = max(1.5 * smoothed_rtt
-                           + max_ack_delay, kMinTLPTimeout)
+        if (bytes_in_flight < 2400):
+          // Less than one full-sized packet in flight.
+          tlp_timeout = max(1.5 * smoothed_rtt
+                              + max_ack_delay, kMinTLPTimeout)
+        else:
+          tlp_timeout = max(1.5 * smoothed_rtt,

I believe the `1.5` here should be `2` according to the text you have above.

> @@ -365,7 +352,11 @@ receiver.
 The timer duration, or Probe Timeout (PTO), is set based on the following
 conditions:
 
-* PTO SHOULD be scheduled for max(1.5*SRTT+MaxAckDelay, kMinTLPTimeout)
+* If less than 2400 bytes are in flight, PTO SHOULD be scheduled for

Having this somewhat magic number here just feels weird. This is the number of bytes 'we, locally' have in flight right? So don't we know our current sending MTU? Can't it just be two times that?

-- 
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/1796#pullrequestreview-158577350