Opened 4 years ago

Last modified 3 months 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 (15)

comment:1 Changed 4 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 4 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 4 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 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:8 Changed 2 years ago by nickm

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

comment:9 Changed 9 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 9 months ago by nusenu (previous) (diff)

comment:10 Changed 6 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 6 months ago by cypherpunks

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

comment:13 Changed 6 months ago by teor

Parent ID: #21501

comment:14 in reply to:  2 Changed 5 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 3 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?

Note: See TracTickets for help on using tickets.