On Thu, Jan 21, 2021 at 2:59 AM Yuchung Cheng <ych...@google.com> wrote: > > On Wed, Jan 20, 2021 at 6:59 AM Neal Cardwell <ncardw...@google.com> wrote: > > > > On Wed, Jan 20, 2021 at 5:50 AM Pengcheng Yang <yan...@wangsu.com> wrote: > > > > > > hi, > > > > > > I have a doubt about tcp_rearm_rto(). > > > > > > Early TCP always rearm the RTO timer to NOW+RTO when it receives > > > an ACK that acknowledges new data. > > > > > > Referring to RFC6298 SECTION 5.3: "When an ACK is received that > > > acknowledges new data, restart the retransmission timer so that > > > it will expire after RTO seconds (for the current value of RTO)." > > > > > > After ER and TLP, we rearm the RTO timer to *tstamp_of_head+RTO* > > > when switching from ER/TLP/RACK to original RTO in tcp_rearm_rto(), > > > in this case the RTO timer is triggered earlier than described in > > > RFC6298, otherwise the same. > > > > > > Is this planned? Or can we always rearm the RTO timer to > > > tstamp_of_head+RTO? > > > > > > Thanks. > > > > > > > This is a good question. As far as I can tell, this difference in > > behavior would only come into play in a few corner cases, like: > > > > (1) The TLP timer fires and the connection is unable to transmit a TLP > > probe packet. This could happen due to memory allocation failure or > > the local qdisc being full. > > > > (2) The RACK reorder timer fires but the connection does not take the > > normal course of action and mark some packets lost and retransmit at > > least one of them. I'm not sure how this would happen. Maybe someone > > can think of a case.
Yes, and it also happens when an ACK (a cumulative ACK covered out-of-order data) is received that makes ca_state change from DISORDER to OPEN, by calling tcp_set_xmit_timer(). Because TLP is not triggered under DISORDER and tcp_rearm_rto() is called before the ca_state changes. > > > > My sense would be that given how relatively rare (1)/(2) are, it is > > probably not worth changing the current behavior, given that it seems > > it would require extra state (an extra u32 snd_una_advanced_tstamp? ) > > to save the time at which snd_una advanced (a cumulative ACK covered > > some data) in order to rearm the RTO timer for snd_una_advanced_tstamp > > + rto. > > also there's an experimental proposal > https://tools.ietf.org/html/rfc7765 > > so Linux actually implements that in a limited way that only applies > in specific scenarios. > > > > > neal Thank you for answering my questions.
