Opened 12 years ago

Closed 10 years ago

Last modified 8 years ago

#871 closed enhancement (wontfix)

Allow Advertiseing of Dirport with accounting max enabled

Reported by: Jon Owned by:
Priority: Low Milestone: post 0.2.1.x
Component: Core Tor/Tor Version:
Severity: Keywords:
Cc: Jon, nickm, pdc, arma, Sebastian Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by nickm)

One should be able to choose how to spend the bandwidth. Currently when accounting max is
enabled, the Dirport is not advertised.

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (13)

comment:1 Changed 11 years ago by nickm

Mini-design proposal: add a new configuration option, "AccountingMaxDirPercent X" that says, "if accounting is in use,
do not use more than X% of our bandwidth serving directory info." If this option is 0, you get current behavior.
If this option is 100, DirPort use can be as high as your AccountingMax. By default, this option will be 0.

Is this reasonable? Would this do what you want, do you think?

comment:2 Changed 11 years ago by Jon

Absolutely - Yes, thank you. Both DirPort and OrPort usage count towards the same accountingmax I gather?

comment:3 Changed 11 years ago by nickm

Actually, hang on. Right now all bandwidth is tracked together, so it's not actually easy to see how much has been used
for directory stuff in the accounting subsystem. It wouldn't be as easy as I'd thought to build something like this.

Also, it's not necessarily a great idea. Accounting is a limit on the number of bytes read, and a limit on the number
of bytes written. [The limit applies to each, not to their sum.] If we're being a relay or an exit, bytes read is
about the same as bytes written, so we are using the input bytes _and_ the output bytes. If, on the other hand, we
serve directory stuff, then we use up all the output bytes, and we never get to actually use the input bytes. That's
inefficient; a server like that is way more useful to the network as a relay.

Now, we might try to establish separate limits for read and write. But that wouldn't be too useful: most people with
asymmetric limits have more read bandwidth than write bandwidth, which is the opposite of what you'd need to be a
good directory.

Alternatively, we might have the option for a combined limit of read _plus_ write. If that's what your limit is,
being a directory wouldn't hurt. Nobody has ever asked for that kind of accounting, though, which leads me to think
it isn't how their ISPs are capping their traffic. If it is, then we should maybe have an option to do accounting
as read plus write.

Roger, what are your thoughts here?

comment:4 Changed 11 years ago by nickm

(In any case, we should have better documentation or messages about *why* we're turning off the dirport because of

comment:5 Changed 11 years ago by arma

Right. I think we should close this as 'wontimplement'. The only cases that I know
of where people want this feature are if they have like 10 terabytes a month, and
they want to do accountingmax just in case, but they also want to be maximally useful.

The reality is that having a dirport open really isn't that useful. As long as most
Tors do, we have plenty of directory mirrors, and the few people in the '10 tb/mo but
need accountingmax on' case aren't a big difference either way.

The bytes spent on TLS connections are way more valuable than bytes spent on dir
mirroring. That was my motivation for just turning off dirport if accountingmax
is set, rather than trying to complexify the code in some way.

comment:6 Changed 11 years ago by nickm

Actually, I think that some people _are_ limited on read-plus-write rather than on max(read, write) ; I'm taking a
straw poll now. The easiest thing to do here would be to add a feature to let people pick sum or max as their
accounting method, and let sum people be directories, and give max people a useful message about why they don't
want to be directories.

(okay, the next easiest thing after saying "wontimplement.")

comment:7 Changed 11 years ago by nickm

Handling read+write accounting would be a new feature, and hence would have to come in 0.2.2.x, since 0.2.1.x is already
in feature freeze.

comment:8 Changed 11 years ago by arma

Some people who want accountingmax only want it so Tor will keep the
bw_accounting file up to date.

So another option would be to add an alternate accountingmax mechanism --
one that tracks bytes and puts them in the file, so people can track their
usage, but it never actually hibernates.

comment:9 Changed 10 years ago by Sebastian

How about we open the DirPort, so people get the behaviour of a node
with DirPort open, but don't advertise it?

comment:10 Changed 10 years ago by arma

Sebastian: that's already the current behavior.

comment:11 Changed 10 years ago by arma

To clarify: the current behavior is that we open the dirport, and fetch
directory information for our cache on the same schedule as somebody else
with an open dirport. The only difference is that when we publish our relay
descriptor, we say 0 for the dirport. That's the signal to clients that we
don't want to waste energy on our dirport.

comment:12 Changed 10 years ago by nickm

Description: modified (diff)
Resolution: Nonewontfix
Status: newclosed

I'm going to call this "wontfix" for now: there are a few bugs/enhancements discussed here, but the main one this bug is about is not at all critical, unless we find ourselves in danger of running out of directory caches, which we aren't.

The sum vs max thing is bug #961 .

comment:13 Changed 8 years ago by nickm

Component: Tor RelayTor
Note: See TracTickets for help on using tickets.