[IPFIX] tcpControlBits, ECN, and IE-DOCTORS
Brian Trammell <[email protected]>
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
Greetings, all, I note that the definition of IE 6, tcpControlBits, uses the RFC793 definition of the TCP Flags byte, ignoring the changes to the definition of this field made by RFC3168 (ECN). The "must be zero" language here has two unfortunate consequences: (1) it obliges MP implementors to mask the field by 0x3F to zero out bytes that may be set in headers due to ECN negotiation and (2) it makes it impossible to use compliant implementations to measure ECN negotiation. I have verified that the at least one shipping implementation of NetFlow V9 follows the IANA definition; it does indeed mask 0x3F, destroying ECN negotiation information. Yes, I know "nobody uses ECN" but recent active measurement efforts have shown increased default support for ECN negotiation; see e.g. Honda et al. in IMC 2011. I'd considered the right way to address this in view of the proposed IE-DOCTORS process; a change adding ECE and CWR to tcpControlBits would indeed appear to be eligible for an updated IE on first pass per section 5.2 (it harmonizes with an updated external reference (3168 updates 793, though the update happened before the definition of IPFIX); it also defines a previously reserved bit in an IE with flag semantics). However, tcpControlBits is in the magic lower 128 V9-compatible space; new IEs in this space require V9 expert approval, but changes (as yet) do not. Should this be corrected? Cheers, Brian _______________________________________________ IPFIX mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipfix