Caching learned MSS/MTU values

Templin, Fred L Fred.L.Templin at boeing.com
Fri Oct 18 17:17:28 CEST 2013


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.

Thanks - Fred
fred.l.templin at boeing.com

> 
> Greetings,
> 
>   Hannes


More information about the ipv6-ops mailing list