Hi Hannes, > -----Original Message----- > From: Hannes Frederic Sowa [mailto:han...@stressinduktion.org] > Sent: Friday, October 18, 2013 9:24 AM > To: Templin, Fred L > Cc: Jason Fesler; IPv6 operators forum > Subject: Re: Caching learned MSS/MTU values > > 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.
Yes, I had heard that there was an off-by-default linux implementation of RFC4821. I also heard that it was not yet fully compliant to the spec, but that was a while ago now and it may have gotten better by now? > I still have to take a closer look at SEAL. Thanks for the reminder. ;) Sure. I have recently published an alpha linux implementation of SEAL: http://www.ietf.org/mail-archive/web/ipv6/current/msg19114.html It is still in early phases and does not yet fully implement the spec but does implement the core RFC4821 path MTU probing and fragmentation requirements for several different varieties of tunnels. The code is also quite ugly, and I would welcome any help on cleaning it up and/or implementing more features in the spec. Thanks - Fred fred.l.temp...@boeing.com > Greetings, > > Hannes
