Date: Mon, 02 May 2005 16:48:35 +0200 From: Andre Oppermann <andre@freebsd.org> To: Qing Li <qingli@speakeasy.net> Cc: freebsd-current@freebsd.org Subject: Re: FW: pmtu patch Message-ID: <42763DC3.38CC2DD6@freebsd.org> References: <20050430023040.3AC1D43D53@mx1.FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Qing Li wrote:
> -----Original Message-----
> From: Qing Li [mailto:qingli@FreeBSD.org]
> Sent: Thursday, April 28, 2005 5:36 PM
> To: andre@freebsd.org
> Cc: qingli@freebsd.org
> Subject: pmtu patch
>
> Hi Andre,
>
> I was thinking whether we could add another variable
> in "hc_metrics" called "u_long rmx_mtu_lastupdate" and
> perhaps a new function called "tcp_hc_getmtu_update"
>
> When we get the ICMP PRC_MSGSIZE notification, we do
>
> if (((time_second() - tcp_hc_getmtu_update(&inc)) < PMTU_MIN)
> do_nothing;
> else {
> ...
> }
>
> If there is no suggested mtu value, instead of immediately
> falling back to the default, or rely on the original
> packet fragment, can we just use the mtu value in the
> host cache as the basis for the next try as in:
>
> else {
>
> <set new value for rmx_mtu_lastupdate>
>
> mtu = ip_next_mtu(tcp_hc_getmtu(&inc), 1);
>
> }
IMO this is too complicated for too little actual value. It's not
that we are supposed to run into this problem all the time. David's
idea provides a very easy way to work around the problem without
requiring any state tracking.
--
Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42763DC3.38CC2DD6>