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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CADVnQykgYGc4_U+eyXU72fky2C5tDQKuOuQ=BdfqfROTG++w7Q@mail.gmail.com>
Date:   Wed, 20 Jan 2021 09:59:00 -0500
From:   Neal Cardwell <ncardwell@...gle.com>
To:     Pengcheng Yang <yangpc@...gsu.com>
Cc:     Yuchung Cheng <ycheng@...gle.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 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.

neal