Opened 9 years ago

Closed 3 years ago

#5190 closed task (fixed)

Collect Rob's patch for throttling flows at guards

Reported by: arma Owned by: robgjansen
Priority: Medium Milestone: Tor: 0.3.2.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: performance, scheduling, SponsorZ, tor-relay, review-group-18
Cc: robgjansen Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by arma)

Rob's NDSS poster has graphs showing various ways of choosing how to throttle flows at entry guards. We should collect these patches for posterity.

Also we should see if the most promising of them need to be cleaned up before we'd want to put them into 0.2.4 as a thing to do a realistic experiment on.

Child Tickets

Change History (24)

comment:1 Changed 9 years ago by arma

Keywords: performance flowcontrol added

comment:2 Changed 9 years ago by arma

Description: modified (diff)

comment:3 Changed 9 years ago by arma

Keywords: scheduling added; flowcontrol removed

comment:4 Changed 8 years ago by karsten

Keywords: SponsorZ added

I was told that there's now also a USENIX paper on this topic.

Making this a sponsor Z ticket. The task would be to compare the different algorithms for entry nodes to do the throttling, pick one of the patches, clean it up, and merge it into 0.2.4.x.

comment:5 Changed 8 years ago by robgjansen

The three algorithms described in the paper are located in my github Tor clone. The branches are:

  • throttle-bitsplit
  • throttle-flag
  • throttle-threshold

They are currently at an alpha release of 0.2.3 (I can't remember which), and will have to be merged into master. That shouldn't be too bad.

comment:6 Changed 8 years ago by nickm

Keywords: tor-relay added

comment:7 Changed 8 years ago by nickm

Component: Tor RelayTor

comment:8 Changed 8 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

comment:9 Changed 7 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.???

comment:10 Changed 4 years ago by cass

Severity: Normal

This ticket is tagged SponsorZ, but it looks like progress stalled years ago. Is this still a thing that needs funding? Has the issue been addressed by other dev work?

comment:11 Changed 4 years ago by nickm

This could be quite valuable if we do it.

comment:12 Changed 4 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:13 Changed 4 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:14 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:15 Changed 3 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.3.2.x-final
Status: newneeds_review

Rob, I found this ticket while I was going through the Tor: Unspecified milestone. Should we still consider these branches, or should we assume that they're 5 years old and no longer what we ought to do?

comment:16 Changed 3 years ago by robgjansen

The throttling techniques in these patches attempt to distinguish persistent bulk flows from bursty flows using approaches based on unsupervised learning. I would want additional analysis before recommending these get deployed as-is.

We could consider providing a torrc option where clients could opt-in and announce to relays that they want to be throttled, labeling their circuits as worse-priority circuits. Guards could then throttled those clients to reduce the load that those worse-priority circuits impose on the network. This would remove the tricky unsupervised learning parts and greatly simplify the algorithms. Not sure who would opt-in though...

Last edited 3 years ago by robgjansen (previous) (diff)

comment:17 Changed 3 years ago by nickm

Keywords: review-group-18 added

comment:18 Changed 3 years ago by nickm

Owner: set to rogbjansen
Status: needs_reviewassigned

setting owner

comment:19 Changed 3 years ago by nickm

Status: assignedneeds_review

comment:20 Changed 3 years ago by robgjansen

Owner: changed from rogbjansen to robgjansen
Status: needs_reviewassigned

This was assigned to me, but I'm not sure why. Could someone clarify that please?

Is some type of throttling something that is seriously being considered for merge? It's unlikely that I will have a significant amount of time within the next six months to push this forward enough to make it merge-able, but I'm happy to provide guidance if someone else plans to wear that hat.

comment:21 Changed 3 years ago by nickm

I'd put this as needs_review under the impression that somebody should be looking at the code at some point. If that's not so, we can put it back into "tor:unspecified".

The "assigned" event was to set you as the owner, since (I think?) you wrote the original code here?

comment:22 Changed 3 years ago by nickm

FWIW, Rob -- this ticket is mainly about trying to get you to make the patches public. Is that something you can do?

comment:23 Changed 3 years ago by robgjansen

I believe that my patches have been public since I talked to Roger and he made this ticket. (See my comment above.)

The code currently publicly exists on in these branches:

  • research/throttling/bitsplit
  • research/throttling/flag
  • research/throttling/threshold

AIUI, Tor doesn't generally "archive" research code. Perhaps this case was different because of the potential positive impact that throttling could have on general Tor usage? In any case, I don't plan on removing my code from my GitHub Tor clone linked above, but do feel free to "collect" it in some way if that is desirable.

I think we can close this ticket. If we indeed want to further pursue it, deciding if throttling should actually be done and how should probably be a new ticket.

comment:24 Changed 3 years ago by nickm

Resolution: fixed
Status: assignedclosed

Great! Thanks, Rob! And sorry for my confusion.

Note: See TracTickets for help on using tickets.