Fix IP ECN codepoint for SACK retransmissions (RFC3168)

[rscheff]

Summary

retransmissions during SACK loss recovery are not using adjusted snd_nxt and thus get marked as ECT0, not strictly according to RFC3168.
This is addressing Bug report 243231.

Note that this behavior is in-line with ECN++ (work in progress @ IETF).

Since this interaction between ECN and SACK has been in production, it must have had similar exposure as ECN itself...

Further note that the compliant RFC3168 behavior might lead to higher RTO rates, as not-ECT marked retransmissions are prone to higher loss rates in congested enviornments, if the oversaturated queue could still mark packets with CE instead of dropping. With other words, this patches an RFC compliance violation, but might result in less good performance in existing ECN deployments.

Test Plan

packetdrill script - set up a session with ECN negotiated, and also SACK enabled. Observe the IP ECN codepoint of the retransmission when not acknowleding transmitted data by packetdrill.

[rgrimes]

How did you run into this one?

[rscheff]

Testing and validating Cubic with ECN (and implicitly SACK) over two simulated congestion points (one with ECN, one loss-based).

[rscheff]

• rexmit w/o ip ect mark now in rack too

[rscheff]

Randall, can you please validate that this is sufficient for the RACK stack?

I see that when you do rack resends, that the sack_rxmit is also set - can you confirm that this should always be the case (also for TLP resends)?

[cc]

Did not find any problem in bsd11.