Hi all, I recently posted a draft proposal for traffic splitting for Tor: https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/329-t... It has similar properties as TurboTunnel, but I put quite a bit of work and consulted with several TCP and multipath TCP researchers to develop the packet scheduling algorithms defined in Section 3: https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/329-t... You may be interested in adopting those algorithms, if possible. There are variants that optimize for latency, throughput, or both in combination. The proposal also supports resumption of closed circuits. I am writing this mail because while these things are nice, resumption in particular does not defend against all classes of issues I am worried about with respect to confirmation attacks from closing or blocking connections, particularly onion service connections: https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/329-t... Briefly, if an adversary suspects an onion service is in use at a particular guard, it can make a circuit to that onion service, hold it open, and then close TCP connections of that guard to see if the circuit closes. This can even be done on the side with TCP RST injection, and possibly even blindly with brute force RST spoofing and spamming, if a good enough guess can be made about the IP address range of the service. Worse, in this case, the resumption I specified for Conflux does not help here, because this adversary will see the service's resumption attempt, and use that for confirmation instead of circuit close. TurboTunnel's resumption and automatic bridge discovery and replacement should greatly mitigate this attack, because it happens at a layer that is not necessarily controlled by the adversary, and thus resumption is mostly invisible to them (save for delay, which Cecylia is working on minimizing). Additionally, since traffic splitting has been shown to help against website fingerprinting, it stands to reason that doing traffic splitting at multiple layers and multiple endpoints may actually be better than doing it at just one layer, and costs us little-to-nothing in terms of overhead: https://www.comsys.rwth-aachen.de/fileadmin/papers/2020/2020-delacadena-traf... So please, keep on improving TurboTunnel! And let's compare notes about what we learn! Looking forward to obfs4 TurboTunnel, too! -- Mike Perry