Just to point a few things out about the data and how Ben and I have interpreted it:
> Short version: Ben Stasiewicz's research into significant > (33/404 = 8%) levels of PMTUD failure in IPv6 - > are tunnels causing a lot of this? Your 8% figure might be a lot less if you take into account the 214 too smalls. Ben fetched a large object from each webserver (>1280 bytes) and advertised a 1221 MSS, so it should have been enough to get a large response to then PTB. If we are only seeing 1280 byte packets then this could indicate a 1280 tunnel in the path we cannot see, but which is sending PTBs. That case would be defined as PMTUD success. Ben is working on collecting data from multiple VPs to try and get to the bottom of this. > The 214 servers classed as "RX_TOSMALL" were those where the > HTTP server returned packets too small to perform the PMTUD > test. Perhaps this was a tweak to avoid PMTUD problems which > are apparently not uncommon (33/404) in IPv6 at present. My understanding is the tweek that people use to get this behaviour is to set the interface MTU to 1280. The MSS values advertised by the server do not support this as the major contribution to too-smalls, as 60 systems seemed to have interfaces clamped to 1280 (mss 1220). The MSS frequencies are included in http://listserver.internetnz.net.nz/pipermail/ipv6-techsig/2009-October/000708.html _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
