netdev - Re: [PATCH net-next v2 3/5] tcp_cubic: switch bictcp

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]

Date:   Fri, 27 Dec 2019 07:24:38 -0800
From:   Eric Dumazet <edumazet@...gle.com>
To:     Neal Cardwell <ncardwell@...gle.com>
Cc:     "David S . Miller" <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Eric Dumazet <eric.dumazet@...il.com>,
        Soheil Hassas Yeganeh <soheil@...gle.com>,
        Yuchung Cheng <ycheng@...gle.com>,
        Martin KaFai Lau <kafai@...com>
Subject: Re: [PATCH net-next v2 3/5] tcp_cubic: switch bictcp_clock() to usec resolution

On Fri, Dec 27, 2019 at 6:46 AM Neal Cardwell <ncardwell@...gle.com> wrote:
>
> On Mon, Dec 23, 2019 at 3:28 PM Eric Dumazet <edumazet@...gle.com> wrote:
> >
> > Current 1ms clock feeds ca->round_start, ca->delay_min,
> > ca->last_ack.
> >
> > This is quite problematic for data-center flows, where delay_min
> > is way below 1 ms.
> >
> > This means Hystart Train detection triggers every time jiffies value
> > is updated, since "((s32)(now - ca->round_start) > ca->delay_min >> 4)"
> > expression becomes true.
> >
> > This kind of random behavior can be solved by reusing the existing
> > usec timestamp that TCP keeps in tp->tcp_mstamp
> ...
> > @@ -438,7 +431,7 @@ static void bictcp_acked(struct sock *sk, const struct ack_sample *sample)
> >         if (ca->epoch_start && (s32)(tcp_jiffies32 - ca->epoch_start) < HZ)
> >                 return;
> >
> > -       delay = (sample->rtt_us << 3) / USEC_PER_MSEC;
> > +       delay = sample->rtt_us;
>
> It seems there is a bug in this patch: it changes the code to not
> shift the RTT samples left by 3 bits, and adjusts the
> HYSTART_ACK_TRAIN code path to expect the new behavior, but does not
> change the HYSTART_DELAY code path to expect the new behavior, so the
> HYSTART_DELAY code path is still shifting right by 3 bits, when it
> should not... the HYSTART_DELAY remains like this at the end of the
> patch series:
>
>         if (hystart_detect & HYSTART_DELAY) {
> ...
>                         if (ca->curr_rtt > ca->delay_min +
>                             HYSTART_DELAY_THRESH(ca->delay_min >> 3)) {
>
> AFAICT the patch also should have:
>
> -                            HYSTART_DELAY_THRESH(ca->delay_min >> 3)) {
> +                           HYSTART_DELAY_THRESH(ca->delay_min)) {
>


I do not think so Neal.

The HYSTART_DELAY_THRESH(ca->delay_min >> 3) thing really means we
want to apply a 12.5 % factor.

See commit 42eef7a0bb09 "tcp_cubic: refine Hystart delay threshold"
for some context.

After this patch, ca->delay_min is in usec unit, and ca->cur_rtt is
also in usec unit.

Thanks !