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....@lists.cluenet.de > > [mailto:ipv6-ops-bounces+fred.l.templin=boeing....@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
