On 2014-11-09 22:10, Lorenzo Colitti wrote: > On Sat, Nov 8, 2014 at 11:48 PM, Jeroen Massar <jer...@massar.ch > <mailto:jer...@massar.ch>> wrote: > > >> The issue with IPv6 access to Google should now be resolved. Please > let > >> us know if you're still having problems. > > The fun question of course is: what/why/how the heck happened? > > > Another fun question is why folks are relying on PMTUD instead of > adjusting their MTU settings (e.g., via RAs).
Because why would anybody want to penalize their INTERNAL network? Does Google run non-1500 MTU internally? I hope you are running JumboPackets at least internally (the ~9000 ones, not the 65k+ ones in IPv6 thought ;) Also, nobody knows if a packet somewhere in the middle of the path to their destination will have a non-1500 MTU. > But relying on PMTUD still > imposes a 1-RTT penalty on every TCP connection to an IPv6 address you > haven't talked to in the last few minutes. Why would you do that to your > connection? Because you can't know if that is always the case. > As to what happened: what happened here is that some Google servers > temporarily stopped doing MSS clamping. That was an outage, and AIUI it > has since been fixed. Thanks for admitting AND explaining what the problem is. As you work at Google, ever heard of this QUIC protocol that does not use TCP? Maybe you want to ask your colleagues about that :) > (Some parts of) Google infrastructure do not do > PMTUD for the latency reasons above and for reasons similar to those > listed > in https://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem-00 . As such, you are ON PURPOSE breaking PMTUD, instead trying to fix it with some other bandaid. And thus you are hiding problems that will happen when QUIC actually starts to get used? Or are you going to just reset the Internet to 1280? :) Greets, Jeroen
