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-next>] [day] [month] [year] [list]
Message-ID: <45EBFD13.1060106@symas.com>
Date:	Mon, 05 Mar 2007 03:20:51 -0800
From:	Howard Chu <hyc@...as.com>
To:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: TCP 2MSL on loopback

Why is the Maximum Segment Lifetime a global parameter? Surely the 
maximum possible lifetime of a particular TCP segment depends on the 
actual connection. At the very least, it would be useful to be able to 
set it on a per-interface basis. E.g., in the case of the loopback 
interface, it would be useful to be able to set it to a very small duration.

As I note in this draft 
http://www.ietf.org/internet-drafts/draft-chu-ldap-ldapi-00.txt
when doing a connection soak test of OpenLDAP using clients connected 
through localhost, the entire port range is exhausted in well under a 
second, at which point the test stalls until a port comes out of 
TIME_WAIT state so the next connection can be opened.

These days it's not uncommon for an OpenLDAP slapd server to handle tens 
of thousands of connections per second in real use (e.g., at Google, or 
at various telcos). While the LDAP server is fast enough to saturate 
even 10gbit ethernet using contemporary CPUs, we have to resort to 
multiple virtual interfaces just to make sure we have enough port 
numbers available.

Ideally the 2MSL parameter would be dynamically adjusted based on the 
route to the destination and the weights associated with those routes. 
In the simplest case, connections between machines on the same subnet 
(i.e., no router hops involved) should have a much smaller default value 
than connections that traverse any routers. I'd settle for a two-level 
setting - with no router hops, use the small value; with any router hops 
use the large value.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   Chief Architect, OpenLDAP     http://www.openldap.org/project/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ