netdev - Re: RFC: Nagle latency tuning

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: <20080922.184012.212424947.davem@davemloft.net>
Date:	Mon, 22 Sep 2008 18:40:12 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	andi@...stfloor.org
Cc:	csnook@...hat.com, rick.jones2@...com, netdev@...r.kernel.org
Subject: Re: RFC: Nagle latency tuning

From: Andi Kleen <andi@...stfloor.org>
Date: Tue, 23 Sep 2008 02:14:09 +0200

> Typical case: you got a large company network behind a NAT.
> First user has a very crappy wireless connection behind a slow
> intercontinental link talking to the outgoing NAT router. He connectes to 
> your internet server first and the window, slow start etc. parameters 
> for him are saved in the dst_entry.  
> 
> The next guy behind the same NAT is in the same building
> as the router who connects the company to the internet. He
> has a much faster line. He connects to the same server. 
> They will share the same dst and inetpeer entries.
> 
> The parameters saved earlier for the same IP are clearly invalid
> for the second case. The link characteristics are completely 
> different.

Just as typical are setups where the NAT clients are 1 or 2
fast hops behind the firewall.

There are many cases where perfectly acceptible heuristics
don't perform optimally, this doesn't mean we disable them
by default.

> Also did you know there are there are whole countries behind
> NAT.

I am more than aware of this, however this doesn't mean it is
sane and this kind of setup makes many useful internet services
inaccessible.

> Ah I see there's a sysctl now to disable this. How about
> setting it by default?

It's for debugging.
--
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