Date: Thu, 22 Sep 2005 11:50:02 +0200 From: Jeremie Le Hen <jeremie@le-hen.org> To: Sten Daniel =?iso-8859-1?Q?S=F8rsdal?= <lists@wm-access.no> Cc: freebsd-net@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: UDP dont fragment bit Message-ID: <20050922095002.GN24643@obiwan.tataz.chchile.org> In-Reply-To: <4331956A.2060406@wm-access.no> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050922095002.GN24643>