Deploy TCP Fast Open at exits (and maybe inter-node?)

Most of our network runs on Linux, and TCP Fast Open (https://en.wikipedia.org/wiki/TCP_Fast_Open, https://tools.ietf.org/html/rfc7413) has been supported by Linux since 3.6, and enabled by default since 3.13. You have to use special socket APIs on the client side to use it, though, so we need to patch Tor to make use of it.

If we turned this on at Tor exits, I would guess it would make most of the exit connections 1xRTT, since cookies would be shared by all clients using that exit, and for popular destination servers, odds will be high that a given exit has connected to server recently.

I'm not sure the inter-node case will help as much, but maybe.. However, if we do use it, we'll need to be extra careful not to use it for Tor clients (or bridges), to avoid linkability.

changed milestone to %Tor: unspecified

added component::core tor/tor exit milestone::Tor: unspecified needs-analysis performance priority::medium severity::normal status::new term-project tor-relay type::enhancement labels

Hrmm. Actually, this is likely an unsafe default, even if the Tor app is using optimistic data. From reading https://tools.ietf.org/html/rfc7413#section-6.3.1, it sounds like it shouldn't be used for POST requests..

I guess I will close this as invalid, since I don't think we have a way to signal from the SOCKS port to Tor that we'd want to use something like this just for some connections.

Trac:
Resolution: N/A to invalid
Status: new to closed

Yawning and I discussed briefly on IRC that we might be able to get away with doing TFO just for exit traffic destined to port 443, since TLS should be fine with issues in section 6, and sketch non-TLS 443 servers shouldn't be advertising/accepting TFO.

Reopening while we ponder that case.

Trac:
Resolution: invalid to N/A
Status: closed to reopened

Also, if we do want the application to inform Tor that it wants this feature over socks, proposal 229 would give us a way to do so.

Trac:
Sponsor: N/A to N/A
Milestone: N/A to Tor: 0.2.???

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

Trac:
Milestone: Tor: 0.3.??? to Tor: unspecified
Keywords: N/A deleted, tor-03-unspecified-201612 added

Remove an old triaging keyword.

Trac:
Keywords: tor-03-unspecified-201612 deleted, N/A added

Trac:
Status: reopened to new
Keywords: performance deleted, performance tor-relay exit needs-analysis term-project added
Reviewer: N/A to N/A
Severity: N/A to Normal

FreeBSD comes also with TCP Fast Open support (client and server side) and has it enabled by default since FreeBSD 12 (client side). https://svnweb.freebsd.org/base?view=revision&revision=330001 https://svnweb.freebsd.org/base?view=revision&revision=335610

Nowadays Windows also have TFO Support by default. It can speed up bootstrapping. Reconnecting time of updated or up-and-down or hibernated nodes or expired connections also inter-node. Most benefit for Exit nodes.

https://trac.torproject.org/projects/tor/wiki/org/meetings/2018Rome/Notes/OptimisticData

Trac:
Parent: N/A to #21501 (moved)

yes and every non keep-alive client connections will benefit from it

Trac:
Parent: #21501 (moved) to N/A

Replying to mikeperry:

Yawning and I discussed briefly on IRC that we might be able to get away with doing TFO just for exit traffic destined to port 443, since TLS should be fine with issues in section 6, and sketch non-TLS 443 servers shouldn't be advertising/accepting TFO.

Reopening while we ponder that case.

hello, i suggest split this work to get it done quicker.

1. while concerning about privacy, this decisions may need review first. Why not open a child ticket for this maybe?

2. implementation in inter-relay and client=>guard connection seems to be without any possible privacy impacts yet. why don't just enable TFO(TCP Fast Open) in alpha testing branch for this TLS only connections?

Hello, for the inter-relay question. Please read code inside:

+++ src/core/or/channelpadding.c
@@ -617,7 +617,10 @@ channelpadding_get_channel_idle_timeout(

TL;DR

Canonical relay-to-relay channels  only last for 45..75min or consensus +/- 25%

I tested this and found out, that on extending through a relay, to a given node can have high cbt on first because TLS handshaking inter relay. Next CircuitBuildTime will be better, because multiplexing above existing orcon. But later used, the same behavior repeats!

So, the relay could benefit from reestablishing the connections. giving better latency for circuits. This have no privacy impacts. Why don't just enable TFO in alpha branch for this TLS channels?

so not only exit node can benefit but all nodes when talking inter-node. because tcp is not keepalive kept connected very long. less for clients that do single tcp multiplex through guards. but clients extending with TFO enabled hops get faster circuitbuildtimes!

the question is not, what platforms do support but which ones does not make use of TFO yet? all known that tor can run on are supported to date.

enabling TFO usage into alpha for all roles but exit first, should give good results with no known side effects and be good to go experienced further with later enabling exiting TLS connection ?

mentioned in issue #21501 (moved)

moved to tpo/core/tor#16682