[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADVnQymCNEtQFThsbQ0u7jirx24i45f5L7P-2dPf8omkshqwmg@mail.gmail.com>
Date: Tue, 29 May 2018 12:03:46 -0400
From: Neal Cardwell <ncardwell@...gle.com>
To: marcelo.leitner@...il.com
Cc: Michael Tuexen <michael.tuexen@...chi.franken.de>,
nhorman@...driver.com, Dmitry Vyukov <dvyukov@...gle.com>,
lucien.xin@...il.com, Netdev <netdev@...r.kernel.org>,
linux-sctp@...r.kernel.org, David Miller <davem@...emloft.net>,
dsa@...ulusnetworks.com, Eric Dumazet <edumazet@...gle.com>,
syzkaller@...glegroups.com
Subject: Re: [PATCH net] sctp: not allow to set rto_min with a value below 200 msecs
On Tue, May 29, 2018 at 11:45 AM Marcelo Ricardo Leitner <
marcelo.leitner@...il.com> wrote:
> - patch2 - fix rtx attack vector
> - Add the floor value to rto_min to HZ/20 (which fits the values
> that Michael shared on the other email)
I would encourage allowing minimum RTO values down to 5ms, if the ACK
policy in the receiver makes this feasible. Our experience is that in
datacenter environments it can be advantageous to allow timer-based loss
recoveries using timeout values as low as 5ms, e.g.:
https://www.ietf.org/proceedings/97/slides/slides-97-tcpm-tcp-options-for-low-latency-00.pdf
https://tools.ietf.org/html/draft-wang-tcpm-low-latency-opt-00
cheers,
neal
Powered by blists - more mailing lists