Date: Wed, 21 Sep 2005 14:32:07 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= <lists@wm-access.no> Cc: freebsd-net@FreeBSD.org Subject: Re: UDP dont fragment bit Message-ID: <20050921142903.J34322@fledge.watson.org> In-Reply-To: <43315E6F.1020003@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050921142903.J34322>