netdev - Re: [PATCH] tcp: Increase the initial congestion window to 10.

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: <alpine.DEB.2.00.1102042126440.28937@melkinpaasi.cs.helsinki.fi>
Date:	Fri, 4 Feb 2011 21:43:14 +0200 (EET)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	"H.K. Jerry Chu" <hkjerry.chu@...il.com>
cc:	David Miller <davem@...emloft.net>,
	Netdev <netdev@...r.kernel.org>, therbert@...gle.com,
	Jerry Chu <hkchu@...gle.com>
Subject: Re: [PATCH] tcp: Increase the initial congestion window to 10.

On Thu, 3 Feb 2011, H.K. Jerry Chu wrote:

> On Thu, Feb 3, 2011 at 2:43 PM, Ilpo Järvinen <ilpo.jarvinen@...sinki.fi> wrote:
> > It would perhaps be useful to change receiver advertized window to include
> > some extra segs initially. It should be >= IW + peer's dupThresh-1 as
> > otherwise limited transmit won't work for the initial window because we
> > won't open more receiver window with dupacks (IIRC, I suppose Jerry might
> > be able to correct me right away if I'm wrong and we open window with
> > dupacks too?).
> 
> Sorry I don't know how the receive window is updated in Linux,
> autotuning or not.
> But I just wonder why would it have to do with dupacks, i.e., why would 
> it not slide forward as long as the left edge of the window slides 
> forward, regardless of OOO pkt arrival?

?? DupACK by defination does not slide the left edge?!? :-) ...It
certainly makes a difference whether the ACK is cumulative or not. 
Anyway, I tcpdumped it now and confirmed that advertized window is not 
advanced if OOO packet arrives.

> I am of the opinion that rwnd is for flow control purpose only thus should be
> fully decoupled from the cwnd of the other (sender) side. Therefore
> initrwnd should
> normally be based on projected BDP and local memory pressure, e.g., 64KB, not
> bearing any relation with IW of the other side. Only under special
> circumstances should it be used to constrain the sender, e.g., for
> devices behind slow links with
> very small buffer.

I also think along the lines that the advertized window autotuning code 
is just unnecessarily preventive (besides the IW change, also Quickstart 
couldn't be used that efficiently because of it).

-- 
 i.