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

[Praveen Balasubramanian <[e-mail]>]

pravb commented on this pull request.



> -
-QUIC includes MaxAckDelay in all probe timeouts, because it assumes the ack
-delay may come into play, regardless of the number of ack-eliciting
-packets in flight. TCP's TLP assumes if at least 2 ack-eliciting packets are
-in flight, acks will not be delayed.
-
-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.
-
-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}}.
+~~~
+PTO = max(smoothed_rtt + 4*rttvar + max_ack_delay, kGranularity)

Quoting RACK draft:

Aiming for a PTO value of 2*SRTT allows a sender to wait long enough
   to know that an ACK is overdue.  Under normal circumstances, i.e. no
   losses, an ACK typically arrives in one SRTT.  But choosing PTO to be
   exactly an SRTT is likely to generate spurious probes given that
   network delay variance and even end-system timings can easily push an
   ACK to be above an SRTT.  We chose PTO to be the next integral
   multiple of SRTT.

   Similarly, network delay variations and end-system processing
   latencies and timer granularities can easily delay ACKs beyond
   2*SRTT, so senders SHOULD add at least 2ms to a computed PTO value
   (and MAY add more if the sending host OS timer granularity is more
   coarse than 1ms).


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