implement TFO aka TCP FAST OPEN to save RTT

from current android to windows versions it is now implement. Why not make use of it? Sure yes, Client to Guard connection would benefit the less.

Trac:
Username: acceleraTor

changed milestone to %Tor: unspecified

added component::core tor/tor milestone::Tor: unspecified parent::16682 priority::low reporter::acceleraTor resolution::duplicate severity::minor status::closed tcp-fast-open tor-client tor-relay type::enhancement labels

I don't think this helps the common cases in a noticeable manner.

There is one long lived TLS connection between the Client and Guard, and inter-relay links converge toward the network being a complete graph. If anything I'd expect this to have more impact on the latter.

Trac:
Version: Tor: unspecified to N/A
Milestone: Tor: 0.3.0.x-final to Tor: unspecified

I guess it might help a tiny bit to do this at the exit?

Trac:
Keywords: tor-client deleted, tor-client tor-relay tcp-fast-open added

Replying to nickm:

I guess it might help a tiny bit to do this at the exit? Of course it will reduce latencys and feeling of connection speed. See: #16682 (moved)

This is a duplicate of #16682 (moved): let's use the ticket that talks about the privacy risks.

Trac:
Status: new to closed
Resolution: N/A to duplicate
Parent: N/A to #16682 (moved)

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?

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

Replying to cypherpunks:

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?

This is a duplicate ticket, let's continue the conversation in #16682 (moved).

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

closed

moved to tpo/core/tor#21501 (closed)