Opened 5 years ago

Last modified 6 weeks ago

#16682 new enhancement

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

Reported by: mikeperry Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: performance tor-relay exit needs-analysis term-project
Cc: yawning, nickm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

TicketTypeStatusOwnerSummary
#21501enhancementclosedimplement TFO aka TCP FAST OPEN to save RTT

Change History (17)

comment:1 Changed 5 years ago by mikeperry

Resolution: invalid
Status: newclosed

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.

comment:2 Changed 5 years ago by mikeperry

Resolution: invalid
Status: closedreopened

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.

comment:3 Changed 5 years ago by nickm

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.

comment:4 Changed 4 years ago by teor

Milestone: Tor: 0.2.???

comment:5 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:6 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

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

comment:7 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:8 Changed 3 years ago by nickm

Keywords: tor-relay exit needs-analysis term-project added
Severity: Normal
Status: reopenednew

comment:9 Changed 13 months ago by nusenu

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

Last edited 13 months ago by nusenu (previous) (diff)

comment:10 Changed 10 months ago by cypherpunks

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.

comment:12 Changed 10 months ago by cypherpunks

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

comment:13 Changed 10 months ago by teor

Parent ID: #21501

comment:14 in reply to:  2 Changed 9 months ago by cypherpunks

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?
  1. 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?

comment:15 Changed 7 months ago by cypherpunks

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?

comment:16 Changed 2 months ago by cypherpunks

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!

Last edited 2 months ago by cypherpunks (previous) (diff)

comment:17 Changed 6 weeks ago by cypherpunks

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 ?

Note: See TracTickets for help on using tickets.