Allow testing ECE and CWR response for "enhanced" measurement

[irl]

No description provided.

[ana-cc]

Hi,
Useful resource for doing this with ipatbles:
https://gist.github.com/bauer1j/1320355/ef7a8aad7373858cc6230f05f2d9c0f02aee5348

[irl]

This is the script that our original measurements were based on, I just couldn't find it again so many years later.

The implementation in #180 which I noticed is thrown in with the traceroute implementation actually doesn't do the right thing. It sets CE on all the packets including the SYN, so doesn't test whether or not we can get CE through the path. A sane ECN implementation wouldn't negotiate ECN if it saw CE on the SYN.

[mirjak]

no we were actually testing use of ECN codepoint on the SYN with that.

[irl]

To test that ECN is not negotiated in those cases?

[mirjak]

This fallback is not part of the standard and as we have published in our common TMA paper that some host do not implement it:

"69.35% of all hosts (33145) only negotiated ECN when the
ECN IP codepoint was set to zeros (non-ECT) but not if ETC0
or CE was set. Only 12.79% of the hosts (8280) negotiated
ECN no matter what codepoint was set on the TCP SYN. 26
hosts negotiated ECN when ECT0 was set but not when CE
was set. While it was expected that some hosts would not
negotiate ECN if CE was set, as this is a known fallback
mechanism to prevent ECN usage on corrupted path, it is
rather surprising how many hosts have implemented this logic
and that most host apply the same fallback to ETC0."

However, the bigger questions here, which is currently discussed in the IETF, is can we use ECN on the SYN (together with AccECN). So actually not negotiating classic ECN if the SYN is marked can be good, however, this is not the only deployed behavior...