netdev - Re: [RFC PATCH RESEND] tcp: avoid F-RTO if SACK and timestamps are disabled

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: <alpine.DEB.2.20.1806291308170.29120@whs-18.cs.helsinki.fi>
Date:   Fri, 29 Jun 2018 13:17:57 +0300 (EEST)
From:   Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
To:     Yuchung Cheng <ycheng@...gle.com>
cc:     Michal Kubecek <mkubecek@...e.cz>, netdev <netdev@...r.kernel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH RESEND] tcp: avoid F-RTO if SACK and timestamps are
 disabled

On Wed, 27 Jun 2018, Yuchung Cheng wrote:

> On Fri, Jun 15, 2018 at 3:35 AM, Ilpo Järvinen
> <ilpo.jarvinen@...sinki.fi> wrote:
> > On Fri, 15 Jun 2018, Michal Kubecek wrote:
> >
> >> My understanding is that this means that while the first ack after new
> >> data is correctly ignored, the following ack which preserves window size
> >> should be recognized as a dupack and (3a) should be taken.
> >
> > Linux FRTO never gets that far (without my fix) if the ACK in step 2
> > covers beyond the RTO rexmit because 3b is prematurely invoked, that's
> > why you never see what would occur if 3a is taken. TCP thinks it's not
> > recovering anymore and therefore can send only new data (if there's some
> > available).
> >
> > This is what I tried to tell earlier, with new data there you see there's
> > something else wrong too with FRTO besides the RTO loop.
>
> agreed. Ilpo do you mind re-submitting your fix
> https://patchwork.ozlabs.org/patch/883654/ (IIRC I already acked-by)

Resent as individual patch. And, no you didn't ack it but my impression
in general is that we have converged into agreement about the sender side 
fixes including this one but I'm hesitant to interpret such vague 
impression about agreement alone as acked-by.

(Now with hindsight, maybe I should have interpreted this statement
of yours above as acked-by and added it but I already did send it out 
without adding it).

> tcptest suite may have to wait due to some internal workload Neal is 
> juggling. 

Ok, no problem. Thanks for keeping me updated.


-- 
 i.