UDP dont fragment bit

Robert Watson rwatson at FreeBSD.org
Wed Sep 21 06:32:08 PDT 2005


On Wed, 21 Sep 2005, Sten Daniel Sørsdal wrote:

> Your assumption is that you can rely on routers in your path to inform 
> you that you that your packet size is causing fragments.
>
> Consider a client connected to an isp's network(1). The isp drops all 
> ICMP packets. That network is then connected to a third network(2) which 
> has a data path that has an MTU of 1400 bytes but also mangles tcp mss 
> to 1360, udp packets must get fragmented. On server size the firewall 
> must reassemble all udp fragments before passing them on to server.
>
> I hope my pseudo-code works for you, the example is over simplified. 
> With DF set:

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.

Robert N M Watson

>
> tcp_socket = tcp_connect_controlchannel_to_server('1.2.3.4);
>
> [ .. transmit and receive hello messages .. ]
> [ .. request datagram size discovery .. ]
>
> int max_size = 1500;
> int found = FALSE;
> while (!$found || max_size == 500)
> {
> 	udp_send_test_datagram('1.2.3.4', max_size);
> 	if ( tcp_receive_message( tcp_socket ) == DATAGRAM_RECEIVED )
> 	{
> 		found = TRUE;
> 		break;			// exit loop
> 	}
> 	max_size = 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.
>
> -- 
> Sten Daniel Sørsdal
>


More information about the freebsd-net mailing list