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
| ||
|
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.
Powered by blists - more mailing lists