Opened 5 weeks ago

Last modified 2 days ago

#27690 new defect

Update bandwidth-file-spec with scaling methods

Reported by: juga Owned by:
Priority: Medium Milestone: sbws 1.0 (MVP must)
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-spec, tor-bwauth
Cc: teor Actual Points:
Parent ID: #27107 Points:
Reviewer: Sponsor:

Description

As commented in #27338, and implemented in #27337 and #27336 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.

Child Tickets

Change History (4)

comment:1 Changed 4 days ago by 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.
Otherwise, should we include/repeat Torflow scaling in this spec?

comment:2 in reply to:  1 ; Changed 3 days ago by 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.

comment:3 in reply to:  2 ; Changed 3 days ago by 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.
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.

comment:4 in reply to:  3 Changed 2 days ago by teor

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.

Note: See TracTickets for help on using tickets.