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: <48D8396E.20008@hp.com>
Date:	Mon, 22 Sep 2008 17:33:50 -0700
From:	Rick Jones <rick.jones2@...com>
To:	Andi Kleen <andi@...stfloor.org>
CC:	David Miller <davem@...emloft.net>, csnook@...hat.com,
	netdev@...r.kernel.org
Subject: Re: RFC: Nagle latency tuning

Andi Kleen wrote:
>>It is not an invalid estimate even in the NAT case, 
> 
> 
> 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.
> 
> Also did you know there are there are whole countries behind
> NAT. e.g. I was told that all of Saudi Arabia only comes from
> a small handfull of IP addresses. It would surprise me if 
> all of KSA has the same link characteristics? @)

That seems as much of a case against NAT as per-destintation attribute 
caching.

If my experience at "a large company" is any indication, for 99 
connections out of 10 I'm going through a proxy rather than NAT so all 
the remote server sees are the characteristics of the connection between 
it and the proxy.

And even if I were not, how is per-destination caching the possibly 
non-optimal characteristics based on one user behind a NAT really 
functionally different than having to tune the system-wide defaults to 
cover that corner-case user?  Seems that caching per-destination 
characteristics is actually limiting the alleged brokenness to that 
destination rather than all destinations?

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