netdev - Re: [PATCH net-next] tcp: introduce rto_max

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] [day] [month] [year] [list]

Message-ID: <CAL+tcoAZxz3OAZvDPYaQd3Gdmb9zpHy4iX_F6AJDLGp70VZX_A@mail.gmail.com>
Date: Tue, 16 Jul 2024 16:26:41 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: kuba@...nel.org, pabeni@...hat.com, davem@...emloft.net, 
	dsahern@...nel.org, ncardwell@...gle.com, corbet@....net, 
	netdev@...r.kernel.org, Jason Xing <kernelxing@...cent.com>
Subject: Re: [PATCH net-next] tcp: introduce rto_max_us sysctl knob

On Tue, Jul 16, 2024 at 4:11 PM Jason Xing <kerneljasonxing@...il.com> wrote:
>
> On Tue, Jul 16, 2024 at 3:14 PM Jason Xing <kerneljasonxing@...il.com> wrote:
> >
> > On Tue, Jul 16, 2024 at 2:57 PM Eric Dumazet <edumazet@...gle.com> wrote:
> > >
> > > On Mon, Jul 15, 2024 at 11:42 PM Jason Xing <kerneljasonxing@...il.com> wrote:
> > > >
> > > > Hello Eric,
> > > >
> > > > On Mon, Jul 15, 2024 at 10:40 PM Eric Dumazet <edumazet@...gle.com> wrote:
> > > > >
> > > > > On Sun, Jul 14, 2024 at 8:31 PM Jason Xing <kerneljasonxing@...il.com> wrote:
> > > > > >
> > > > > > From: Jason Xing <kernelxing@...cent.com>
> > > > > >
> > > > > > As we all know, the algorithm of rto is exponential backoff as RFC
> > > > > > defined long time ago.
> > > > >
> > > > > This is weak sentence. Please provide RFC numbers instead.
> > > >
> > > > RFC 6298. I will update it.
> > > >
> > > > >
> > > > > > After several rounds of repeatedly transmitting
> > > > > > a lost skb, the expiry of rto timer could reach above 1 second within
> > > > > > the upper bound (120s).
> > > > >
> > > > > This is confusing. What do you mean exactly ?
> > > >
> > > > I will rewrite this part. What I was trying to say is that waiting
> > > > more than 1 second is not very friendly to some applications,
> > > > especially the expiry time can reach 120 seconds which is too long.
> > >
> > > Says who ? I think this needs IETF approval.
> >
> > Did you get me wrong? I mean this rto_max is the same as rto_min_us,
> > which can be tuned by users.
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > Waiting more than one second to retransmit for some latency-sensitive
> > > > > > application is a little bit unacceptable nowadays, so I decided to
> > > > > > introduce a sysctl knob to allow users to tune it. Still, the maximum
> > > > > > value is 120 seconds.
> > > > >
> > > > > I do not think this sysctl needs usec resolution.
> > > >
> > > > Are you suggesting using jiffies is enough? But I have two reasons:
> > > > 1) Keep the consistency with rto_min_us
> > > > 2) If rto_min_us can be set to a very small value, why not rto_max?
> > >
> > > rto_max is usually 3 order of magnitude higher than rto_min
> > >
> > > For HZ=100, using jiffies for rto_min would not allow rto_min < 10 ms.
> > > Some of us use 5 msec rto_min.
> > >
> > > jiffies is plain enough for rto_max.
> >
> > I got it. Thanks.
> >
> > >
> > >
> > > >
> > > > What do you think?
> > >
> > > I think you missed many many details really.
> > >
> > > Look at all TCP_RTO_MAX instances in net/ipv4/tcp_timer.c and ask
> > > yourself how many things
> > > will break if we allow a sysctl value with 1 second for rto_max.
> >
> > I'm not modifying the TCP_RTO_MAX value which is tooooo complicated.
> > Instead, I'm trying to control the maximum expiry time in the
> > ICSK_TIME_RETRANS timer. So it's only involved in three cases:
> > 1) syn retrans
> > 2) synack retrans
> > 3) data retrans
>
> To be clearer, my initial goal is to accelerate the speed of
> retransmitting data. There is a simpler way to implement it only in
> tcp_retransmit_timer().

Sorry to keep replying to this thread so frequently. I have to admit
tuning rto max is much more complicated than rto min. I think simply
reducing the time of retrans is not a feasible way.