Use exponential backoff also for SYN segments

[tuexen]

Summary

Retransmissions of SYN segments should also use exponential backoff right from the beginning as described in the TCP RFCs.

Test Plan

Use an updated version of snd-syn.

[rscheff]

sys/netinet/tcp_timer.c

236 ↗

(On Diff #53226)

I thought the separate table would be retained, just filled with similar values as below.

For example, while trying ECN fallback, not backing off exponentially but retrying linear (for the non ECN handshake) would potentially allow slightly faster session setup.

As an example, linux is over-restrictive on RFC3168 - ECN++ (SYN with ECT set) would get dropped for a significant population of servers, if introduced. At that point, a separate (linear beginning) backoff table may need to be re-introduced.

Suggest to keep the special backoff table for syn, only adjusting the values contained within, ideally for ECN backoff (default of tcp_ecn_maxtries) with a linear first step.

[tuexen]

sys/netinet/tcp_timer.c

236 ↗

(On Diff #53226)

I think have two tables with the same values does not make sense.

We have right now multiple ways of modifying a SYN on retransmissions:

• For ECN we try a number of times before turning off ECN. This number is controlled by the sysctl variable net.inet.tcp.ecn.maxretries, which defaults to 1.
• For SACK, timestamp and window scaling we turn it off after a number of retransmissions which is hardcoded in the kernel as 2.
• For TCP fastopen we turn is off for all retransmissions.

So I think if we want for a particular reason to avoid exponential backoff or reset the number of retransmissions, this has to be coded and (possibly) adjusted to the characteristics of the reason.

Since you are specifically referring to ECN: Right now we would retransmit the first time after 3 seconds and the second time (without ECN) after another 3 seconds. Assuming that ECN is the problem, it would take 6 seconds until the first SYN would make it through. With this change (and the reduction of RTO.Initial), the first retransmission would be after 1 second and the second would be after another 2 seconds. In total this would be 3 seconds instead of 6 seconds.

[rscheff]

Ok, I've could not remember that there are already hardcoded exceptions for TCP options alreads. Since there is precedent that this is an accepted path to deal with special cases (such as ECN++ against a legacy Linux box, should the stack start doing ECN++, of course), i remove my objection.

Speaking of which: Who would be interest in ECN+ and ECN++?

ECN+: Have SYN/ACK with ECT - https://tools.ietf.org/html/rfc5562
ECN++: Have ECT on virtually all TCP segements- https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-03

I suspect we will be looking into this once getting operational expirience with DCTCP.

[rrs]

sys/netinet/tcp_timer.c

236 ↗

(On Diff #53226)

I agree lets not have two tables with the same value.. too confusing :-)