revised Proposal 161: Computing bandwidth adjustments

Nick Mathewson nickm at torproject.org
Fri May 15 17:39:21 UTC 2009


I've pushed Mike's revisions to proposal 161 based on discussion
here.  I have a few questions on the revised version:

>   Two hop circuits are built using nodes from the same slice, and a large
>   file is downloaded via these circuits. For nodes in the first 15% of the
>   network, a 500K file will be used. For nodes in the next 15%, a 250K file
>   will be used. For nodes in next 15%, a 100K file will be used. The 
>   remainder of the nodes will fetch a 75K file.[1]

The "first" 15%?   Do you mean the "fastest"?  And what does the [1]
refer to?

>   This process is repeated 250 times, and average stream capacities are 
>   assigned to each node from these results. 
>   
>   In the future, a node generator type can be created to ensure that
>   each node is chosen to participate in an equal number of circuits,
>   and the selection will continue until every live node is chosen
>   to participate in at least 7 circuits.

By the way, what does the algorithm do with non-running nodes now?
Does it retry them as it goes?  Does a circuit that failed to build
mean anything for the node's capacity?  Does it count to the number of
circuits built?

Also, we'll want to think more about this "until every live node is chosen
to participate in at least 7 circuits" thing before we do it; if 7
random circuits per live node are necessary and sufficient to measure
the nodes' capacities, then we can get away with less (or will have to
handle more) circuits than we're currently planning.  [For example, if
all 50 nodes are live, we'll need about 354 circuits on average.  If
only 30 are live, we'll expect to be done after 201 circuits.]

 [...]
>   This will produce a new bandwidth value that will be output into a 
>   file consisting of lines of the form:
> 
>   node_id=<idhex> SP bw=<Bw_new> NL
>   
>   This file can be either copied or rsynced into a directory readable
>   by the directory authority.

When documenting and building this format, remember to note that
programs parsing it MUST ignore unrecognized line formats and
unrecognized fields on the lines they do recognize.

Otherwise, this looks fine to me.

-- 
Nick 



More information about the tor-dev mailing list