RE: Caching learned MSS/MTU values
Hi Hannes, > Oh, that is interesting. I'll have a look at the weekend. OK. I had to roll another version to make some minor changes - see: http://linkupnetworks.com/seal/sealv2-0.2.tgz http://www.ietf.org/id/draft-templin-intarea-seal-64.txt I will let it rest for now, so this would be the version to start looking at. Let me know if there are any questions or comments. Thanks - Fred fred.l.temp...@boeing.com
Re: Caching learned MSS/MTU values
Hi! On Fri, Oct 18, 2013 at 04:35:39PM +, Templin, Fred L wrote: > > 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? Going through the git logs it does not seem to get a lot of commits. Maybe it is just stable, I don't know. I'll activate it on my boxes now to see if something breaks. The committed patch droped the note that it is not fully spec compliant but seems to be based on the -05 draft. > > 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. Oh, that is interesting. I'll have a look at the weekend. Thanks, Hannes
RE: Caching learned MSS/MTU values
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 +, 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
Re: Caching learned MSS/MTU values
On Fri, Oct 18, 2013 at 03:17:28PM +, 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
RE: Caching learned MSS/MTU values
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. Thanks - Fred fred.l.temp...@boeing.com > > Greetings, > > Hannes
Re: Caching learned MSS/MTU values
Everyone, Thank you.
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. ;) Greetings, Hannes
Re: Caching learned MSS/MTU values
On Thu, Oct 17, 2013 at 09:05:24AM -0700, Jason Fesler wrote: > 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? NetBSD does it on a per-address base - that is, I think, per /128. It's an additional entry in the routing table, like this: 2a01:170:1012:77::25 fe80::20d:61ff:fe46:50ad%xennet0 UGHD 2 27 1280 xennet0 -is
