Caching learned MSS/MTU values

[Hannes Frederic Sowa]

On Fri, Oct 18, 2013 at 03:17:28PM +0000, Templin, Fred L wrote:
> Hi,
> 
> > -----Original Message-----
> > From: ipv6-ops-bounces+fred.l.templin=boeing.com at lists.cluenet.de
> > [mailto:ipv6-ops-bounces+fred.l.templin=boeing.com at lists.cluenet.de] On
> > Behalf Of Hannes Frederic Sowa
> > Sent: Friday, October 18, 2013 12:31 AM
> > To: Jason Fesler
> > Cc: IPv6 operators forum
> > Subject: Re: Caching learned MSS/MTU values
> > 
> > On Thu, Oct 17, 2013 at 09:05:24AM -0700, Jason Fesler wrote:
> > > I'm once again considering trying to improve on the test-ipv6.com
> > PMTUD
> > > failure detection. Due to limitations on the client side I can't use
> > raw
> > > sockets to generate test packets. The client is JavaScript and runs
> > in a
> > > browser; all I can do is try fetching urls from multiple locations,
> > each
> > > with a different MTU.
> > >
> > > I know that the various operating systems tend to cache any PMTUD
> > issues
> > > that they can detect; future connections to that destination will use
> > > smaller packets accordingly. What I can not see to find is an
> > adequate
> > > description of what granularity this gets cached with. /128? /64?
> > Also, I
> > > the absence of Packet Too Big messages, what does each OS do?
> > 
> > Linux, too, does cache on /128 basis. In the absence of PTB the
> > connection
> > will get stuck. ;)
> 
> Right, and we are observing non-negligible cases where PTBs are either
> not delivered or lost somewhere along the way. That is why there is a
> growing push for wider deployment of RFC4821 for end systems, and why
> I am investing my time in developing SEAL for tunnels.

There is basis support for mtu probing for tcp. It is currently deactivated by
default: cat /proc/sys/net/ipv4/tcp_mtu_probing => 0

Guess it had not the seen the testing it needs to activate it by default.

I still have to take a closer look at SEAL. Thanks for the reminder. ;)

Greetings,

  Hannes