We've accumulated a lot of network parameters. Some of them are explicitly intended to be transitional; some of them are probably obsolete. We should come up with a plan to trim the list down.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items ...
Show closed items
Linked items 0
Link issues together to show that they're related.
Learn more.
I believe that we can hardcode these values doing forward:
UseCreateFast=0 -- We don't plan to revert our migration to use ntor for all hops.
UseOptimisticData=1 -- We do not plan to ever turn this off.
perconnbwrate=BandwidthRate, perconnbwburst=BandwidthBurst-- these are tuning options that we have not used.
circwidow=1000 we never changed this, and changing it would hurt performance. Moreover, it will be superceded by @mikeperry's 324-rtt-congestion-control.txt
We need to keep circwindow because we are likely to discover that Tor's old fixed window size clients and exits compete unfairly with clients and exits that support variable window sizes from congestion control. If this happens, we will need to use circwindow to lower the fixed window size of those endpoints to prevent legacy endpoints from causing congestion and soaking up queues, which will impede the perf of well-behaved congestion control endpoints.
@tpo/core are we missing any parameters here that we can deprecate? And are there any parameters in the list above that we should keep as configurable?
I agree that phasing out the ones that are about functionality makes sense. That's UseCreateFast, UseOptimisticData, Support022HiddenServices, UseNTorHandshake.
The ones that are there to enable performance experiments (perconnbwrate/burst, circwindow) I would defer to Mike on, since we want to do various performance experiments, and maybe these aren't the experiments we want to do, or maybe we don't want to close the door on these quite yet because we already have the tooling in place.