Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-relay, tor-dos, 033-must,|  Actual Points:
  security, 033-triage-20180320, |
  033-included-20180320  |
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:26 nickm]:
 > Note that this patch caused 32-bit builds to break.  I've tried to fix
 this with 4aaa4215e7e11f318c5a50124e29dc0b50ce21e1.
 >
 > We should have travis check 32-bit builds somehow if we can.

 Travis doesn't have 32 bit machines yet:
 https://github.com/travis-ci/travis-ci/issues/986

 We could do a 32-bit build and test on 64-bit macOS, but we don't use
 macOS on Travis because it's slow.
 (Homebrew also doesn't support 32-bit libraries on macOS, so we'd have to
 install them through MacPorts, which is slow.)

 I'm not sure if there is a similar option for Linux.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-relay, tor-dos, 033-must,|  Actual Points:
  security, 033-triage-20180320, |
  033-included-20180320  |
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by nickm):

 Fixed another compile-time warning in the tests, this time with
 46795a7be63b9a1b90a59fcf9efda4f4f1eacc37

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-relay, tor-dos, 033-must,|  Actual Points:
  security, 033-triage-20180320, |
  033-included-20180320  |
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by nickm):

 Note that this patch caused 32-bit builds to break.  I've tried to fix
 this with 4aaa4215e7e11f318c5a50124e29dc0b50ce21e1.

 We should have travis check 32-bit builds somehow if we can.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-relay, tor-dos, 033-must,|  Actual Points:
  security, 033-triage-20180320, |
  033-included-20180320  |
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by nickm):

 * status:  merge_ready => closed
 * resolution:   => fixed


Comment:

 Thanks; merging!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos, 033-must,|  Actual Points:
  security, 033-triage-20180320, |
  033-included-20180320  |
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_revision => merge_ready


Comment:

 See branch: `ticket24782_033_01`.

 I cherry picked the commits from ahf's branch and addressed nickm's review
 in fixup `418d1ac115babbe6`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos, 033-must,|  Actual Points:
  security, 033-triage-20180320, |
  033-included-20180320  |
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by nickm):

 * status:  merge_ready => needs_revision


Comment:

 Hang on -- this branch seems to be based on master.

 Please do the remaining comment tweak, and base it on maint-0.3.3?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos, 033-must,|  Actual Points:
  security, 033-triage-20180320, |
  033-included-20180320  |
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by nickm):

 One more comment tweak needed -- I'll do it postmerge.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos, 033-must,|  Actual Points:
  security, 033-triage-20180320, |
  033-included-20180320  |
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 Thanks ahf. Love it. Sorry about the nitpick!

 lgtm;

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos, 033-must,|  Actual Points:
  security, 033-triage-20180320, |
  033-included-20180320  |
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by ahf):

 * status:  needs_revision => needs_review


Comment:

 Updated comment.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos, 033-must,|  Actual Points:
  security, 033-triage-20180320, |
  033-included-20180320  |
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 lgtm; except for one comment in the code. Putting it back in
 needs_revision but after that, it should go in `merge_ready`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos, 033-must,|  Actual Points:
  security, 033-triage-20180320, |
  033-included-20180320  |
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * reviewer:   => dgoulet


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos, 033-must,|  Actual Points:
  security, 033-triage-20180320, |
  033-included-20180320  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by ahf):

 * status:  needs_information => needs_review


Comment:

 Patch in https://github.com/torproject/tor/pull/37

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos, 033-must,|  Actual Points:
  security, 033-triage-20180320, |
  033-included-20180320  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Do we have a handle on what most of the use is, when the memory use gets
 huge?

 I ask because if it's queued cells on circuits, the proposed work on
 #25226 should help us to kill problematic circuits before they trigger the
 OOM.

 And we might want to expand that technique to tackle other categories of
 things, where if we can identify a "woah that is using way more than it
 should" situation we can take care of it before the OOM killer has to do
 it.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos, 033-must,|  Actual Points:
  security, 033-triage-20180320, |
  033-included-20180320  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by ahf):

 We should probably come up with a decision here on what we'd like to do
 for us to get this into 033 (if we think it's still important).

 I think David's comment in comment 11 looks reasonable, but reaching some
 kind of consensus would be good.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+-
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-dos, 033-must,|  Actual Points:
  security   |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  tor-relay, tor-dos, 033-must => tor-relay, tor-dos, 033-must,
 security


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
--+
 Reporter:  teor  |  Owner:  ahf
 Type:  defect| Status:
  |  needs_information
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-relay, tor-dos, 033-must  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * keywords:  tor-relay, tor-dos => tor-relay, tor-dos, 033-must
 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.3.x-final


Comment:

 Replying to [comment:9 teor]:
 > Ok, so do we want to hold off on this change?
 > Or do we want to try 0.4*Total RAM?

 I'm up for it. Tor badly estimate the limit for the OOM :S...

 Big relays probably have huge amount of RAM (total) like 32 or 64GB so
 this would mean a limit of 12GB or 25GB with `0.4` which possibly is way
 over estimated anyway.

 For a 2GB relay, it would be 800MB. I think 1GB or even 1.2GB would be
 better but it is a good start.

 We could also do that computation than look at the "Available memory" and
 if it is lower than our estimation, we adjust without going below the
 minimum. But that can back fire if the machine uses lots of memory and a
 minute later frees half of it, tor wouldn't adapt unless we make that a
 moving target.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-ddos  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+
Changes (by teor):

 * status:  assigned => needs_information


Comment:

 Ok, so do we want to hold off on this change?
 Or do we want to try 0.4*Total RAM?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-ddos  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+

Comment (by dgoulet):

 Replying to [comment:6 teor]:
 > Replying to [comment:5 dgoulet]:
 > > We could also explore the possibility for that value to be a moving
 target at runtime. It is a bit more dicy and complicated but because Tor
 at startup looks at the "Total memory" instead of the "Available memory"
 to estimate that value, things can go badly quickly if 4/16 GB of RAM are
 available which will make Tor use 12GB as a limit... and even with a
 fairly good amount of swap, this is likely to be killed by the OOM of the
 OS at some point.
 > >
 > > On the flip side, a fast relay stuck with an estimation of 1GB or 2GB
 of RAM that Tor can use at startup won't be "fast" for much long before
 the OOM kicks in and start killing old circuits.
 >
 > This is not what I have observed. I have some fast Guards. Under normal
 load they don't ever use much more than 1 - 2 GB total RAM.

 Oh that was in the context of the ongoing "DDoS" on the network. I also
 usually never go above 1.2GB for a ~12MB/s relay but right now I'm at ~3GB
 so an estimation at 1GB of RAM would just decrease my relay capabilities.

 > If the fastest relay can do 1 Gbps, then that's 125 MB per second. 12 GB
 of RAM is 100 seconds of traffic. Is it really useful to buffer 100
 seconds of traffic? (Or, under the current load, tens of thousands of
 useless circuits?)
 >
 > So I'm not sure if using more RAM for queues actually helps. In my
 experience, it just increases the number of active connections and CPU
 usage. I don't know how to measure if this benefits or hurts clients. (I
 guess I could tweak my guard and test running a client through it?)

 I think this could come down to lots of traffic being queued because the
 next hops are overloaded so if you relay is very big, Tor is happy to keep
 it while waiting to relay the cells to the much slower next hop. However,
 I'm seriously uncertain about this and if it is even really what is
 happening... Need more investigation on my part.

 [snip]

 Yeah the rest of your response is good knowledge and I'm honestly also
 uncertain of what to do for now either.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-ddos  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+

Comment (by yawning):

 Replying to [comment:6 teor]:
 > > I do believe right now that the network is still fairly usable because
 we have big Guards able to use 5, 10, 12GB of RAM right now... Unclear to
 me if firing up the OOM more frequently would improve the situation but we
 should be very careful at not making every relays using a "too low amount
 of ram" :S.
 >
 > If the fastest relay can do 1 Gbps, then that's 125 MB per second. 12 GB
 of RAM is 100 seconds of traffic. Is it really useful to buffer 100
 seconds of traffic? (Or, under the current load, tens of thousands of
 useless circuits?)

 No, but you don't have a choice because you can't drop cells except if
 things are going catastrophically wrong and you're willing to tear down
 the circuit.

 http://yuba.stanford.edu/~nickm/papers/sigcomm2004.pdf

 However as the paper says:
 > It is a little difficult to persuade the operator of a
 > functioning, profitable network to take the risk and remove
 > 99% of their buffers. But that has to be the next step, and
 > we see the results presented in this paper as a first step
 > towards persuading an operator to try it.

 (The CoDel work also supports their hypothesis.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-ddos  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+

Comment (by teor):

 Replying to [comment:5 dgoulet]:
 > We could also explore the possibility for that value to be a moving
 target at runtime. It is a bit more dicy and complicated but because Tor
 at startup looks at the "Total memory" instead of the "Available memory"
 to estimate that value, things can go badly quickly if 4/16 GB of RAM are
 available which will make Tor use 12GB as a limit... and even with a
 fairly good amount of swap, this is likely to be killed by the OOM of the
 OS at some point.
 >
 > On the flip side, a fast relay stuck with an estimation of 1GB or 2GB of
 RAM that Tor can use at startup won't be "fast" for much long before the
 OOM kicks in and start killing old circuits.

 This is not what I have observed. I have some fast Guards. Under normal
 load they don't ever use much more than 1 - 2 GB total RAM.

 > It is difficult to tell what a normal fast relay will endure in terms of
 RAM for Tor overtime but so far of what I can tell with my relays, between
 1 and 2 GB is usually what I see (in non-DoS condition and non-Exit).

 I usually see 1-2 GB for non-exits, and closer to 2 GB for exits.

 > I do believe right now that the network is still fairly usable because
 we have big Guards able to use 5, 10, 12GB of RAM right now... Unclear to
 me if firing up the OOM more frequently would improve the situation but we
 should be very careful at not making every relays using a "too low amount
 of ram" :S.

 If the fastest relay can do 1 Gbps, then that's 125 MB per second. 12 GB
 of RAM is 100 seconds of traffic. Is it really useful to buffer 100
 seconds of traffic? (Or, under the current load, tens of thousands of
 useless circuits?)

 So I'm not sure if using more RAM for queues actually helps. In my
 experience, it just increases the number of active connections and CPU
 usage. I don't know how to measure if this benefits or hurts clients. (I
 guess I could tweak my guard and test running a client through it?)

 Here's what happened when I followed my own advice in this thread:
 https://lists.torproject.org/pipermail/tor-relays/2018-January/014021.html

 I have a few big guards that are very close to a lot of the new clients.
 They were using 150% CPU, 4-8 GB RAM, and 15000 connections each. But they
 were not actually carrying much useful traffic.

 I tried reducing MaxMemInQueues to 2 GB and 1 GB, and they started using
 3-7 GB RAM. This is on 0.3.0 with the destroy cell fix. (But on my slower
 Guards and my Exit, MaxMemInQueues worked really well, reducing the RAM
 usage to 0.5 - 1.5 GB, without reducing the consensus weight.)

 I tried reducing the number of file descriptors, that reduced the CPU to
 around 110%, because the new connections were closed earlier. It pushed a
 lot of the sockets into the kernel TIME_WAIT state, about 10,000 on top of
 the regular 10,000. (Maybe these new Tor clients didn't do exponential
 backoff?)

 I tried DisableOOSCheck 0, and it didn't seem to make much difference to
 RAM or CPU, but it made a small difference to sockets (and it makes sure
 that I don't lose important sockets, like new control port sockets, so I
 left it on).

 I already set RelayBandwidthRate, but now I also set
 MaxAdvertisedBandwidth to about half the RelayBandwidthRate. Hopefully
 this will make the clients go elsewhere. But this isn't really a solution
 for the network.

 So I'm out of options to try and regulate traffic on these guards. And I
 need to have them working in about a week or so, because I need to run
 safe stats collections on them.

 I think my only remaining option is to drop connections when the number of
 connections per IP goes above some limit. From the tor-relays posts, it
 seems like up to 10 connections per IP is normal, but these clients will
 make hundreds of connections at once. I think I should DROP rather than
 RST, because that forces the client to timeout, rather than immediately
 making another connection.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-ddos  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+

Comment (by dgoulet):

 We could also explore the possibility for that value to be a moving target
 at runtime. It is a bit more dicy and complicated but because Tor at
 startup looks at the "Total memory" instead of the "Available memory" to
 estimate that value, things can go badly quickly if 4/16 GB of RAM are
 available which will make Tor use 12GB as a limit... and even with a
 fairly good amount of swap, this is likely to be killed by the OOM of the
 OS at some point.

 On the flip side, a fast relay stuck with an estimation of 1GB or 2GB of
 RAM that Tor can use at startup won't be "fast" for much long before the
 OOM kicks in and start killing old circuits. It is difficult to tell what
 a normal fast relay will endure in terms of RAM for Tor overtime but so
 far of what I can tell with my relays, between 1 and 2 GB is usually what
 I see (in non-DoS condition and non-Exit).

 I do believe right now that the network is still fairly usable because we
 have big Guards able to use 5, 10, 12GB of RAM right now... Unclear to me
 if firing up the OOM more frequently would improve the situation but we
 should be very careful at not making every relays using a "too low amount
 of ram" :S.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-ddos  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+

Comment (by teor):

 I'm still seeing some of my Guards use 5-7 GB even with the destroy cell
 fix and MaxMemInQueues 2 GB. They have 11000 - 16 connections open
 each. (This is process RAM, and they don't use KISTLite.) So I think this
 supports decreasing the default for systems with a lot of RAM.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-ddos  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 FWIW, I would expect that the kistlite bug #24671 fixed in 0.3.2.8-rc
 might have made Tor use way too much kernel ram; we can take this change,
 but we should keep monitoring Tor's memory usage to see whether our
 estimates are right.  (Also, over time, we should make MaxMemInQueues
 cover more and more of the things that Tor allocates for.  But that
 doesn't affect this ticket.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-ddos  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+
Changes (by ahf):

 * owner:  (none) => ahf
 * status:  new => assigned


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-ddos  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+

Comment (by teor):

 This was split off #24737.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs