A couple bits to add to the discussion. Michael Richardson: > The boxes that are responsible for 90% of the ICMP lossage were also > intolerant of the ECN options in TCP, and pretty much all TCP options in > general. This is not quite right, IMO. In the past there have been problems with packets with the ECN bits set getting through the network (see the original TBIT SIGCOMM paper - available from http://www.icir.org/tbit/). However, our recent measurements show that this is not as much of a problem anymore. And, contrary the the above assertion, blocking based on ECN is not nearly as prevalent as PMTUD failure. Our measurements do not speak to whether the boxes that block ECN also block PMTUD. If someone has such measurements, we'd love to hear about them. Masataka Ohta: > > The good news is that known or unknown TCP options are not blocked > > on paths to web servers. Or at any rate, the connection still > > succeeds in being established... > > As long as routers are not required to look into TCP options, they are > likely to interoperate even with complex TCP options. The trouble is that it just isn't routers getting their grimy hands on our packets these days. Middleboxes look at, touch and mangle packets for all sorts of reasons (from transparent caches to performance enhancing proxies to normalizers to protocol scrubbers to load balancers to ....). So, while our measurements show no problems with TCP options, I don't think it is a foregone conclusion, nor not something to keep our collective eye on. allman
Attachment:
pgp00454.pgp
Description: PGP signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf