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]

Message-ID: <CADVnQy=TpVa4_fn=RptPWk+UMjQNV7ROQ9dz-csOX8ZdAcTt4w@mail.gmail.com>
Date:   Fri, 27 Dec 2019 11:07:15 -0500
From:   Neal Cardwell <ncardwell@...gle.com>
To:     Eric Dumazet <edumazet@...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 10:24 AM Eric Dumazet <edumazet@...gle.com> wrote:
>
> 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.

Oops, of course you are right. So sorry, I forgot this >>3 was for the
12.5% factor, and was reading the code too fast, and with too little
caffeine... :-)

Sorry for the noise!

neal