netdev - Re: RE: A Linux TCP SACK Question

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: <1e41a3230804151023s1658a83dye0a2e91d7a98c34@mail.gmail.com>
Date:	Tue, 15 Apr 2008 10:23:56 -0700
From:	"John Heffner" <johnwheffner@...il.com>
To:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
Cc:	"Wenji Wu" <wenji@...l.gov>, Netdev <netdev@...r.kernel.org>
Subject: Re: RE: A Linux TCP SACK Question

On Tue, Apr 15, 2008 at 10:08 AM, Ilpo Järvinen
<ilpo.jarvinen@...sinki.fi> wrote:
> On Tue, 15 Apr 2008, John Heffner wrote:
>  > We can see that in both cases you are getting throttled by
>  > tcp_moderate_cwnd (X_OtherReductionsCM).  I'm not sure offhand why
>  > it's reaching this code - I would have thought that the high
>  > tp->reordering would prevent this.  Ilpo, do you have any insights?
>
>  What makes you think so? It's called from tcp_try_to_open as anyone can
>  read from the source, basically when our state is CA_Disorder (some very
>  small portion might happen in ca_recovery besides that).

This is what X_OtherReductionsCM instruments, and that was the only
thing holding back cwnd.

I just looked at the source, and indeed it will be called on every ack
when we are in the disorder state.  Limiting cwnd to
packets_in_flight() + 3 here is going to prevent cwnd from growing
when the reordering is greater than 3.  Making max_burst at least
tp->reordering should help some, though I'm not sure it's the right
thing to do.

  -John
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html