Re: IPv6 PMTU/MTU related patch for 2.5.31 kernel

[Shirley Ma]

Andi,

I think it needs to be RFC conformance for PMTU to avoid unnecessary
probing PMTU network traffics. For UDP and ICMP which doesn't have any
reference on this kind of route, the route needs to be around for a while
instead of being delete within a very short time even immediately.

Thanks
Shirley Ma

Andi Kleen <[e-mail]>@averell.firstfloor.org on 08/28/2002 02:44:34 AM

Sent by:    [e-mail]

To:    Shirley Ma/Beaverton/IBM@IBMUS
cc:    [e-mail], [e-mail], LTC IPv6
Subject:    Re: IPv6 PMTU/MTU related patch for 2.5.31 kernel

"Shirley Ma" <[e-mail]> writes:

> +           /* If there is no reference to this route, this route will be
> +              deleted by fib6_run_gc() within 30 secs. The cached
decreased
> +              PMTU will be gone. It's possible to be deleted before any
> +              other protocol using it. Then the old larger pmtu will be
used,
> +              which against RFC1981: detect an increase MUST NOT be done
> +              less than 5 minutes after a Packet Too Big Messages has
> +              been received for the given path.
> +            */
> +           dst_hold(&nrt->u.dst);

This seems overkill and could potentially tie up quite a of dst
entries for dubious purposes. This RFC requirement clearly cannot be
followed in all cases, e.g. when you run out of memory for the
destination cache. This is one such case too.

I think only following it when there is still another reference to the
dst entry (e.g. from a socket) is reasonably near the spirit of the
specification.

-Andi