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
pgpL17YYOjD3Z.pgp
Description: PGP signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf