Tuning improvements and UX config

Also has changes file for conflux.

changed milestone to %Tor: 0.4.8.x-freeze

assigned to @mikeperry

mentioned in issue #40781 (closed)

mentioned in issue #40780 (closed)

requested review from @nickm

This looks plausible to me, but I'd suggest getting another review from @dgoulet before merging, or anybody else who understands this code better than I do.

In the meantime I have some nonblocking things that you probably already though of that I'm just mentioning here in case any of them inspires an "ooh good idea!" reaction.

1. Do any of the changes here, particularly in the switch-related stuff in c8341abf, require a corresponding spec change, or are they all too low-level to show up in the proposal?

2. Instead of only making a global "latency vs throughput" switch, do you think it would make sense to have some way to do it on a more fine-grained basis? A couple of possibilities

   • Maybe as with LongLivedPorts, we could have target ports for which we prefer low latency and others for which we prefer throughput. (But would this have security implications somehow if an adversary can make us use the "wrong" port for a protocol?)
   • Maybe we could make this a flag that applied to SocksPort and friends, so that there could be be one SocksPort to use for latency and another to use for throughput.

If you agree with either of the above, please open a ticket so we don't forget. If you don't, then feel free to ignore. :)

Thanks Nick!

1. Do any of the changes here, particularly in the switch-related stuff in c8341abf, require a corresponding spec change, or are they all too low-level to show up in the proposal?

Oh yes, I can now fully specify two algorithms in the spec (MinRTT and LowRTT). The low memory versions of these are still uncertain, and Alex thinks we should see if we can get some feedback on usage on iOS from Mike Tigas before we even bother with those. But I can add placeholders for them in the spec, with a brief sketch of what it would look like to minimize OOQ.

David is also out this week, so I will just do a spec update for this ticket for him to look over when he gets back.

2. Instead of only making a global "latency vs throughput" switch, do you think it would make sense to have some way to do it on a more fine-grained basis?

As for LongLivedPorts vs SocksPort vs Global, the reason why we need a global option is because the conflux pool is pre-built: there is no stream or socksport information at the point of circuit construction. We also can't easily refactor it to support two pools in C-Tor, to support both at the same time. I expect our on-demand latency options like this to be made use of in arti, where it will be easier to manage such things.

It will also be far more important for WebRTC than for most TCP things. In TCP land, the latency use cases also tend to be low bandwidth, and if you are using not much bandwidth, LowRTT will automatically prefer the lower latency circuit first before switching over, so you will effectively get good responsiveness anyway for those kinds of light use cases.

The spec MR is torspec!132 (merged)

It has some additional clarity improvements. The commit specific to these alg changes is: mikeperry/torspec@0d332d86

approved this merge request

approved this merge request

merged