From owner-freebsd-net Mon Nov 26 11:47: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 44CD237B416 for ; Mon, 26 Nov 2001 11:47:02 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id fAQJl0321324; Mon, 26 Nov 2001 14:47:00 -0500 (EST) (envelope-from wollman) Date: Mon, 26 Nov 2001 14:47:00 -0500 (EST) From: Garrett Wollman Message-Id: <200111261947.fAQJl0321324@khavrinen.lcs.mit.edu> To: Jonathan Lemon Cc: net@FreeBSD.ORG Subject: Re: decreasing TIME_WAIT duration(T/TCP?) In-Reply-To: <200111261443.fAQEhu185094@prism.flugsvamp.com> References: <200111261443.fAQEhu185094@prism.flugsvamp.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > Unfortunately, this is not calculated; we still rely on a static > (default 30sec) MSL quiet period. Ideally, it should be possible to > set MSL based on some multiple of RTT for the connection, and default > to a hard coded value if there are not enough samples to calculate RTT. There is no way to `calculate' the maximum segment lifetime unless you are omniscient. It is assumed to be 30 seconds, but in reality can be much, much more. (As a result, TCP is theoretically broken, but the situations in which this happens are rare enough to be masked by other events.) The RTT gives you the *critical path length* of the graph; it does not have anything to do with the MSL except for trivial (two-node) networks. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message