Update bandwidth-file-spec with scaling methods

As commented in #27338 (moved), and implemented in #27337 (moved) and #27336 (moved) we should update the spec with the scaling method we would use. Since currently it's possible to generate the bandwidth files using different scaling methods, we should first decide which one to use during the transition from torflow to sbws and which one we would use after the transition.

changed milestone to %Tor: 0.4.0.x-final

added component::core tor/tor milestone::Tor: 0.4.0.x-final owner::juga parent::27107 priority::medium resolution::implemented reviewer::teor severity::normal status::closed tor-bwauth tor-spec type::enhancement labels

Maybe we should not include any scaling method, and instead create a bandwidth scaling specification when we come out with an algorithm that is tested enough we are happy with. Otherwise, should we include/repeat Torflow scaling in this spec?

Replying to juga:

Maybe we should not include any scaling method, and instead create a bandwidth scaling specification when we come out with an algorithm that is tested enough we are happy with.

We should delete the parts of the spec that we aren't going to implement soon.

Otherwise, should we include/repeat Torflow scaling in this spec?

Yes, because eventually we will delete the torflow repository and spec. Also, torflow's scaling spec is hard to find, and it is buried in a whole lot of other specs for code that is not used.

Replying to teor:

Replying to juga:

Maybe we should not include any scaling method, and instead create a bandwidth scaling specification when we come out with an algorithm that is tested enough we are happy with.

We should delete the parts of the spec that we aren't going to implement soon.

Otherwise, should we include/repeat Torflow scaling in this spec?

Yes, because eventually we will delete the torflow repository and spec. Also, torflow's scaling spec is hard to find, and it is buried in a whole lot of other specs for code that is not used.

Ok, i'll include Torflow scaling in the bandwidth-file-spec. If torflow repo and spec will be removed, we will lose the parts of torflow that are not about scaling. By the time that would happen, maybe we should have an spec about how the measurements are done and the scaling, both for torflow and sbws.

Replying to juga:

Replying to teor:

Replying to juga:

Maybe we should not include any scaling method, and instead create a bandwidth scaling specification when we come out with an algorithm that is tested enough we are happy with.

We should delete the parts of the spec that we aren't going to implement soon.

Otherwise, should we include/repeat Torflow scaling in this spec?

Yes, because eventually we will delete the torflow repository and spec.

Actually, that's not true - we will archive the repository in the "attic" directory.

Also, torflow's scaling spec is hard to find, and it is buried in a whole lot of other specs for code that is not used.

Ok, i'll include Torflow scaling in the bandwidth-file-spec. If torflow repo and spec will be removed, we will lose the parts of torflow that are not about scaling. By the time that would happen, maybe we should have an spec about how the measurements are done and the scaling, both for torflow and sbws.

We won't archive the torflow repository until we have stopped using torflow. When we've stopped using torflow, we won't need a spec for how it works.

Assign myself

Trac:
Status: new to assigned
Owner: N/A to juga

I think we should remove or change the paragraph in https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt#n488, because with graphs we made later, we could see that they have different shape and Torflow scaled bandwidth was closer to the descriptor observed-bandwidth. What we could verify, is that the raw measurements between Torflow and sbws are close.

Should we also describe the PID control feedback method or only the method without?. I think that if we are not describing other parts on how Torflow works now, then we should not include it either, since it is not being used.

Replying to juga:

Should we also describe the PID control feedback method or only the method without?. I think that if we are not describing other parts on how Torflow works now, then we should not include it either, since it is not being used.

Let's focus on documenting sbws, not torflow.

https://github.com/torproject/torspec/pull/37

Trac:
Status: assigned to needs_review

Trac:
Reviewer: N/A to teor

I put a review on the pull request. Looks good! Thanks!

Trac:
Status: needs_review to needs_revision

Trac:
Status: needs_revision to needs_review

I didn't realise you were waiting for a review on this. I was waiting for answers to my questions.

Sorry!

Trac:
Status: needs_review to merge_ready

Putting this in a tor milestone so it gets merged to torspec.

Trac:
Type: defect to enhancement
Milestone: sbws 1.0 (MVP must) to Tor: 0.4.0.x-final

merged!

Trac:
Resolution: N/A to implemented
Status: merge_ready to closed

closed

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