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: <AANLkTimGjUN6ZuCLhKX-A6h6PytL4eKPGTdzF7OtSuBd@mail.gmail.com>
Date:	Fri, 4 Feb 2011 19:39:46 -0800
From:	Jerry Chu <hkchu@...gle.com>
To:	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
Cc:	David Miller <davem@...emloft.net>,
	Netdev <netdev@...r.kernel.org>, therbert@...gle.com
Subject: Re: [PATCH] tcp: Increase the initial congestion window to 10.

On Fri, Feb 4, 2011 at 11:43 AM, Ilpo Järvinen
<ilpo.jarvinen@...sinki.fi> wrote:
>
> 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.

Cwnd discounts packets that have left the network but rwnd won't discharge
packets until they are consumed by ULP so you are right that in case
the packets from or near the head of the retransmission queue get
dropped rwnd won't
open up room for more packets even though cwnd will. To cover that case initrwnd
needs to be larger than initcwnd.

Jerry

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