netdev - Re: tcp: rearm RTO timer does not comply with RFC6298

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 20 Jan 2021 10:58:02 -0800
From:   Yuchung Cheng <ycheng@...gle.com>
To:     Neal Cardwell <ncardwell@...gle.com>
Cc:     Pengcheng Yang <yangpc@...gsu.com>,
        Netdev <netdev@...r.kernel.org>,
        Eric Dumazet <edumazet@...gle.com>
Subject: Re: tcp: rearm RTO timer does not comply with RFC6298

On Wed, Jan 20, 2021 at 6:59 AM Neal Cardwell <ncardwell@...gle.com> wrote:
>
> On Wed, Jan 20, 2021 at 5:50 AM Pengcheng Yang <yangpc@...gsu.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.
>
> 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