Page MenuHomeFreeBSD

Use exponential backoff also for SYN segments

Authored by tuexen on Jan 25 2019, 9:04 PM.



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.

Diff Detail

rS FreeBSD src repository
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

tuexen created this revision.Jan 25 2019, 9:04 PM
Herald added a subscriber: imp. · View Herald Transcript
rscheff added inline comments.Jan 27 2019, 8:17 AM
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 added inline comments.Jan 27 2019, 7:14 PM
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 accepted this revision.Jan 27 2019, 10:31 PM

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 -
ECN++: Have ECT on virtually all TCP segements-

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

rrs accepted this revision.Feb 20 2019, 12:08 PM
rrs added inline comments.
236 ↗(On Diff #53226)

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

This revision is now accepted and ready to land.Feb 20 2019, 12:08 PM
This revision was automatically updated to reflect the committed changes.