From owner-freebsd-net@FreeBSD.ORG Thu Sep 22 09:50:10 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC2B216A41F; Thu, 22 Sep 2005 09:50:10 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F65543D45; Thu, 22 Sep 2005 09:50:10 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by smtp3-g19.free.fr (Postfix) with ESMTP id F09D12398F; Thu, 22 Sep 2005 11:50:04 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 1DD6E405D; Thu, 22 Sep 2005 11:50:03 +0200 (CEST) Date: Thu, 22 Sep 2005 11:50:02 +0200 From: Jeremie Le Hen To: Sten Daniel =?iso-8859-1?Q?S=F8rsdal?= Message-ID: <20050922095002.GN24643@obiwan.tataz.chchile.org> References: <20050918212110.61962.qmail@web54501.mail.yahoo.com> <20050920134408.Y34322@fledge.watson.org> <43313924.9050009@wm-access.no> <20050921114511.D34322@fledge.watson.org> <4331539D.9030204@wm-access.no> <20050921134029.M34322@fledge.watson.org> <43315E6F.1020003@wm-access.no> <20050921142903.J34322@fledge.watson.org> <4331956A.2060406@wm-access.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4331956A.2060406@wm-access.no> User-Agent: Mutt/1.5.10i Cc: freebsd-net@freebsd.org, Robert Watson Subject: Re: UDP dont fragment bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2005 09:50:11 -0000 Hi, > Often there already is need for a tcp connection for authentication, > negotiation and so forth. > > RTT could, among other things, make a discovery process choose how fine > the increments/descrements should be. > > Estimated bandwidth could also help the actual data transport start out > with a more situation correct value. > > However with the abundance of routers modifying TCP MSS correctly > incorrectly and the odd chance that the data path of UDP packets is > different than TCP packets it wouldnt really give anything necessarily > reliable discovery process. And taking advantage of such values could > make the process more complex or less reliable. This is a rather specific case IMHO. BSD community didn't use to take care of such non standard behaviours, AFAIK. What you describe here is not really what's currently stated in RFCs. I would not be in favor of adding such an option in the FreeBSD kernel because, as Robert stated, this doesn't bring anything if not coupled with a non-trivial mechanim that could provide the user with ICMP MTU events. If one adds this option to the manual page, this will lead for sure to have mails emitted on this even list asking for how to retrieve those informations. Furthermore, I ought to add that the algorithm you described in pseudo-code lacks of robustness because of possible network congestion, which means this isn't something one would really see in wide use. In other words, I think the feature you're calling for is really specific to your problem, regarding your current network environnement. The misbehaviour of some particular network-fascist ISP should not reach the FreeBSD source tree. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org >