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: <Pine.LNX.4.64.0804151340580.31800@tesla.psc.edu>
Date:	Tue, 15 Apr 2008 14:00:06 -0400 (EDT)
From:	Matt Mathis <mathis@....edu>
To:	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
cc:	John Heffner <johnwheffner@...il.com>, Wenji Wu <wenji@...l.gov>,
	Netdev <netdev@...r.kernel.org>
Subject: Re: RE: A Linux TCP SACK Question

In some future kernel release, I would consider changing it to limit cwnd to 
be less than packets_in_flight() + reorder + 3(?).  If the network is 
reordering packets, then it has to accept bursts, otherwise TCP can never open 
the window.  The +3 (or some other constant) is still needed because TCP has 
to send extra packets at the point where the window changes.

As an alternative, you could write a research paper on how the network could 
do LIFO packet scheduling so the reordering serves as a congestion signal to 
the stacks.  I bet it would have some really interesting properties.  Oh wait, 
April 1st was 2 weeks ago.

Thanks,
--MM--

On Tue, 15 Apr 2008, John Heffner wrote:

> 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
>