From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 17:16:33 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 921C216A420; Wed, 21 Sep 2005 17:16:33 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from lakepoint.domeneshop.no (lakepoint.domeneshop.no [194.63.248.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FD9843D46; Wed, 21 Sep 2005 17:16:32 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from [192.168.9.8] (14.80-203-184.nextgentel.com [80.203.184.14]) (authenticated bits=0) by lakepoint.domeneshop.no (8.13.4/8.13.4) with ESMTP id j8LHGVxD032080; Wed, 21 Sep 2005 19:16:31 +0200 Message-ID: <4331956A.2060406@wm-access.no> Date: Wed, 21 Sep 2005 19:16:26 +0200 From: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson 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> In-Reply-To: <20050921142903.J34322@fledge.watson.org> X-Enigmail-Version: 0.92.0.0 OpenPGP: id=C308A003 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org 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: Wed, 21 Sep 2005 17:16:33 -0000 Robert Watson wrote: > > On Wed, 21 Sep 2005, Sten Daniel Sørsdal wrote: > > While the below is perfectly valid and useful and should be easy to > implement with andre's proposed change, would you prefer an interface > that allowed you to query the TCP connection and ask it what pathwise > MTU it had already probed for the route? The kernel host cache already > maintains a number of paramaters associated with built TCP connections > to a host, such as the probed PMTU, estimated RTT and variance, > estimated bandwidth, congestion window, and so on. While it wouldn't > necessarily replace logic to reprobe connection conditions, it seems as > though if you're going to go to the trouble of building a separate > control TCP connection, you might as well benefit from what it finds. > > You can find a list of current host cache properties in > src/sys/netinet/tcp_hostcache.c, struct hc_metrics. > 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. -- Sten Daniel Sørsdal