Opened 7 years ago

Last modified 12 months ago

#4682 assigned project

Deal with 'double door' effects because our read and write rate limiting are independent

Reported by: karsten Owned by: arma
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: performance flowcontrol tor-relay needs-design needs-insight
Cc: nickm, tschorsch@…, robgjansen, arthuredelstein Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


In sponsor F deliverable 2 we promised to "build and execute a plan for proposal 182" and to "figure out how it does or does not relate to the N23 congestion control design, to Ian's ideas about Defenestrator, etc."

There are a couple of subtasks to work on here:

  • Review proposal 182 and reword any unclear parts.
  • Review any existing patches for proposal 182 and update them for merging them into master.
  • Run simulations of proposal 182 using ExperimenTor and Shadow.
  • Make a list of designs that are related to proposal 182.
  • Compare proposal 182 to related designs.

Child Tickets

#4671closednickmStart a list of designs that are related to proposal 182Metrics/Analysis
#5323closedDecide whether letting the read bucket go negative is actually helping usMetrics/Analysis
#5334closedMake simulator authors aware of "sparse exit traffic" and "varying directory load" wishlist itemsMetrics/Analysis
#5336closedDo simulations of initial proposal 182 patchMetrics/Analysis

Change History (18)

comment:1 Changed 7 years ago by Flo

Cc: tschorsch@… added

comment:2 Changed 7 years ago by arma

I think the way to tackle this one is to get a patch that does what the proposal suggests (it looks like there is one in #4712 already -- great), and then we should get Rob and Kevin to try it out in their respective simulators.

There are two things to measure: a) does total latency get better for clients, and b) does total used buffer space get better for relays.

I think the proposal authors think it will improve 'a'. The intuitive step I'm missing is: if you read less from the network, how are you possibly going to get the bytes through faster? But maybe it will improve 'b' and not harm 'a', in which case it's still a win.

comment:3 Changed 7 years ago by Flo

Karsten asked me to post the comments we discussed via email here too:

  • We tested the patch (cf. #4712) for several weeks on our relays. In case of non exit and non directory mirrors the results are great: >90% of all cells get forwarded immediately without any measurable latency. According to our measurements this value is at about 70% otherwise only.
  • In case of directory mirrors the results depend on the configured bandwidth, the new introduced parameter "OutgoingBandwidthBurst" (cf. M in proposal 182) and the amount of directory traffic seen at the relay. Overall, we can say it gets better too but there exist some open questions: What is the relationship between OutgoingBandwidthBurst and the configured rate limiting (magic number vs. ratio)? In the end, is OutgoingBandwidthBurst and BandwidthBurst the same?
  • Due to doubts on illegal issues with exit relays our university does not allow us to run them. Thus we could not test the patch in this environment yet.
  • Currently our implementation does not work with bufferevents. For me this seems a bit tricky to implement. In this case we still need to do some work.

comment:4 Changed 7 years ago by karsten

Cc: arma removed
Owner: set to arma
Status: newassigned

Roger said he's already kinda leading this deliverable, so he's fine if I assign this ticket to him.

comment:5 Changed 7 years ago by robgjansen

Cc: robgjansen added

comment:6 Changed 7 years ago by arma

Keywords: performance flowcontrol added
Summary: Evaluate proposal 182 and compare it to other designsDeal with 'double door' effects because our read and write rate limiting are independent

comment:7 Changed 7 years ago by arma

I wrote up in #5334 some thoughts on missing pieces of Experimentor and Shadow that would let us better evaluate how much of a problem this is and whether we've gotten our fix right.

comment:8 Changed 6 years ago by karsten

Milestone: Sponsor F: March 15, 2012Sponsor F: November 1, 2012

Moving to the November milestone, because there's no way we can make March anymore.

comment:9 Changed 6 years ago by karsten

Keywords: SponsorF20121101 added
Milestone: Sponsor F: November 1, 2012

Switching from using milestones to keywords for sponsor deliverables. See #6365 for details.

comment:10 Changed 6 years ago by nickm

Milestone: Tor: unspecified

comment:11 Changed 6 years ago by nickm

Keywords: tor-relay added

comment:12 Changed 6 years ago by nickm

Component: Tor RelayTor

comment:13 Changed 6 years ago by karsten

The November 1 deadline has passed. What's left to do before calling this sponsor F year 2 deliverable done? And what would be a good deliverable summary for the wiki page?

comment:14 Changed 6 years ago by arma

I updated the sponsorf wiki page.

I believe that we can't call this deliverable done, and it will roll over into year3. The patch needs some attention from Tor developers.

comment:15 Changed 19 months ago by nickm

Keywords: SponsorF20121101 removed
Severity: Normal

comment:16 Changed 19 months ago by sjmurdoch

Cc: sjmurdoch removed

comment:17 Changed 19 months ago by nickm

Keywords: needs-design needs-insight added

comment:18 Changed 12 months ago by arthuredelstein

Cc: arthuredelstein added
Note: See TracTickets for help on using tickets.