From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 13:32:08 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 636EE16A421 for ; Wed, 21 Sep 2005 13:32:08 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id D190443D49 for ; Wed, 21 Sep 2005 13:32:07 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 277EA46BB8; Wed, 21 Sep 2005 09:32:07 -0400 (EDT) Date: Wed, 21 Sep 2005 14:32:07 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= In-Reply-To: <43315E6F.1020003@wm-access.no> Message-ID: <20050921142903.J34322@fledge.watson.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> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-228681796-1127309527=:34322" 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 13:32:08 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-228681796-1127309527=:34322 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 21 Sep 2005, Sten Daniel S=F8rsdal wrote: > Your assumption is that you can rely on routers in your path to inform=20 > you that you that your packet size is causing fragments. > > Consider a client connected to an isp's network(1). The isp drops all=20 > ICMP packets. That network is then connected to a third network(2) which= =20 > has a data path that has an MTU of 1400 bytes but also mangles tcp mss=20 > to 1360, udp packets must get fragmented. On server size the firewall=20 > must reassemble all udp fragments before passing them on to server. > > I hope my pseudo-code works for you, the example is over simplified.=20 > With DF set: While the below is perfectly valid and useful and should be easy to=20 implement with andre's proposed change, would you prefer an interface that= =20 allowed you to query the TCP connection and ask it what pathwise MTU it=20 had already probed for the route? The kernel host cache already maintains= =20 a number of paramaters associated with built TCP connections to a host,=20 such as the probed PMTU, estimated RTT and variance, estimated bandwidth,= =20 congestion window, and so on. While it wouldn't necessarily replace logic= =20 to reprobe connection conditions, it seems as though if you're going to go= =20 to the trouble of building a separate control TCP connection, you might as= =20 well benefit from what it finds. You can find a list of current host cache properties in=20 src/sys/netinet/tcp_hostcache.c, struct hc_metrics. Robert N M Watson > > tcp_socket =3D tcp_connect_controlchannel_to_server('1.2.3.4); > > [ .. transmit and receive hello messages .. ] > [ .. request datagram size discovery .. ] > > int max_size =3D 1500; > int found =3D FALSE; > while (!$found || max_size =3D=3D 500) > { > =09udp_send_test_datagram('1.2.3.4', max_size); > =09if ( tcp_receive_message( tcp_socket ) =3D=3D DATAGRAM_RECEIVED ) > =09{ > =09=09found =3D TRUE; > =09=09break;=09=09=09// exit loop > =09} > =09max_size =3D max_size - 1; > } > if ( !$found ) { return ( OPTIMAL_SIZE_NOT_FOUND ); } > > [ .. continue if optimal size was found .. ] > > ----------------------------------- > > DATAGRAM_RECEIVED would be the message/token that indicates the udp test > datagram was received by server. > > --=20 > Sten Daniel S=F8rsdal > --0-228681796-1127309527=:34322--