From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <netdev-owner@vger.kernel.org>
Received: from mail-it0-f43.google.com ([209.85.214.43]:35254 "EHLO
        mail-it0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S933780AbeCGTzZ (ORCPT
        <rfc822;netdev@vger.kernel.org>); Wed, 7 Mar 2018 14:55:25 -0500
Received: by mail-it0-f43.google.com with SMTP id v194so4956136itb.0
        for <netdev@vger.kernel.org>; Wed, 07 Mar 2018 11:55:25 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <CADVnQymDzMKjrZY1WQPiOLXv0mfxcBFTidB_wLqKDSzPvfhjLQ@mail.gmail.com>
References: <1520427569-14365-1-git-send-email-ilpo.jarvinen@helsinki.fi>
 <1520427569-14365-3-git-send-email-ilpo.jarvinen@helsinki.fi> <CADVnQymDzMKjrZY1WQPiOLXv0mfxcBFTidB_wLqKDSzPvfhjLQ@mail.gmail.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Wed, 7 Mar 2018 11:54:43 -0800
Message-ID: <CAK6E8=f0MusOePWRz9q4fSO9avSziGbSiVemSYccwP+61phEhA@mail.gmail.com>
Subject: Re: [PATCH net 2/5] tcp: prevent bogus FRTO undos with non-SACK flows
To: Neal Cardwell <ncardwell@google.com>
Cc: =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= <ilpo.jarvinen@helsinki.fi>,
        Netdev <netdev@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Wed, Mar 7, 2018 at 11:24 AM, Neal Cardwell <ncardwell@google.com> wrote=
:
>
> On Wed, Mar 7, 2018 at 7:59 AM, Ilpo J=C3=A4rvinen <ilpo.jarvinen@helsink=
i.fi> wrote:
> >
> > In a non-SACK case, any non-retransmitted segment acknowledged will
> > set FLAG_ORIG_SACK_ACKED in tcp_clean_rtx_queue even if there is
> > no indication that it would have been delivered for real (the
> > scoreboard is not kept with TCPCB_SACKED_ACKED bits in the non-SACK
> > case). This causes bogus undos in ordinary RTO recoveries where
> > segments are lost here and there, with a few delivered segments in
> > between losses. A cumulative ACKs will cover retransmitted ones at
> > the bottom and the non-retransmitted ones following that causing
> > FLAG_ORIG_SACK_ACKED to be set in tcp_clean_rtx_queue and results
> > in a spurious FRTO undo.
> >
> > We need to make the check more strict for non-SACK case and check
> > that none of the cumulatively ACKed segments were retransmitted,
> > which would be the case for the last step of FRTO algorithm as we
> > sent out only new segments previously. Only then, allow FRTO undo
> > to proceed in non-SACK case.
>
> Hi Ilpo - Do you have a packet trace or (even better) packetdrill
> script illustrating this issue? It would be nice to have a test case
> or at least concrete example of this.
a packetdrill or even a contrived example would be good ... also why
not just avoid setting FLAG_ORIG_SACK_ACKED on non-sack? seems a much
clean fix.

>
> Thanks!
> neal