Opened 3 months ago

Closed 3 weeks ago

#27690 closed enhancement (implemented)

Update bandwidth-file-spec with scaling methods

Reported by: juga Owned by: juga
Priority: Medium Milestone: Tor: 0.4.0.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-spec, tor-bwauth
Cc: teor Actual Points:
Parent ID: #27107 Points:
Reviewer: teor 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 (15)

comment:1 Changed 2 months 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 2 months 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 2 months 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 months 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.

comment:5 Changed 7 weeks ago by juga

Owner: set to juga
Status: newassigned

Assign myself

comment:6 Changed 7 weeks ago by 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.

comment:7 Changed 7 weeks ago by 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.

comment:8 in reply to:  7 Changed 7 weeks ago by teor

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.

comment:9 Changed 7 weeks ago by juga

Status: assignedneeds_review

comment:10 Changed 7 weeks ago by dgoulet

Reviewer: teor

comment:11 Changed 7 weeks ago by teor

Status: needs_reviewneeds_revision

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

comment:12 Changed 5 weeks ago by juga

Status: needs_revisionneeds_review

comment:13 Changed 3 weeks ago by teor

Status: needs_reviewmerge_ready

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

Sorry!

comment:14 Changed 3 weeks ago by teor

Milestone: sbws 1.0 (MVP must)Tor: 0.4.0.x-final
Type: defectenhancement

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

comment:15 Changed 3 weeks ago by nickm

Resolution: implemented
Status: merge_readyclosed

merged!

Note: See TracTickets for help on using tickets.