Re: GSoC proposal

[Scott Bennett <bennett@xxxxxxxxxx>]

     On Fri, 11 Apr 2008 15:47:09 +0200 Baptiste <baptiste@xxxxxxxxxxxx>
wrote:
>> First off, I am not interested in "per circuit" information, and I sincerely
>> hope that tor would refuse to provide such information via its controller
>> interface.  The very idea seems in opposition to the purpose of tor.
>
>Actually, I was thinking to show the bandwidth of a circuit, without
>additional infos, to estimate how fast a circuit may be.

     Again, that kind of thing appears to me to be very much opposed to the
purpose of tor.  Please don't do it.
>
>>      Secondly, the kind of information I am interested in seeing would be
>> primarily focused upon server operations and performance, such as
>> 
>> 	a) the number of exits currently active to each active port,
>
>If I understand well you are interested in knowing the tcp / udp ports 
>contacted by exit connections ?

     For TCP, yes, and the number of TCP connections currently open to each
TCP port.  tor does not, with one exception (see DNSPort and DNSListenAddres),
relay UDP packets.
>
>> 	b) the number of exits to each port during some time interval (e.g.,
>> 	   an hour) for consecutive time intervals (i.e., a way to collect
>> 	   hourly statistics throughout each day),
>
>OK but remember my objective wasn't to collect statistics continuously. 

     Why not?  It could be turned on/off via a line in torrc, I suppose, but
the overhead ought to be trivial enough that it could simply always be
collected.

>Of course, it would be available while monitor run.

     The raw data can best be collected inside tor; most such data would be
really difficult to collect any other way.  Presenting summarized data could
be handled by a monitor communicating with tor via tor's ControlPort, although
certain cumulative totals could be loggable by tor.
>
>> 	c) the number of circuits currently using each existing router
>> 	   connection,
>> 	d) the current, average, and actual maximum number of onion skins
>> 	   queued for decryption over some preceding time period,
>> 	e) the hourly maximum number of onion skins queued for decryption
>> 	   throughout the day,
>> 	f) the number of relay-only circuits currently active,
>> 	g) the number of hidden service introductions/rendezvous connections
>> 	   currently active and during hourly periods throughout the day,
>> 	h) statistics showing how closely (or not) the BandwidthRate and
>> 	   BandwidthBurst targets are being met, and
>> 	i) statistics regarding cells dropped for each of the possible
>> 	   reasons, and
>> 	j) statistics on various directory service operations.
>
>I took note, I think relay's admin would be helped a lot with theses 
>information.
>
>>      Best wishes for a successful project!
>
>Thanks you very much for your suggestions, they are relevant, and I 
>would enjoy to have such data available for my relay :)
>
     De rien.  My guess is that most system administrator types with any
interest in tor would like to be able to see that information, at least upon
occasion.


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:       bennett at cs.niu.edu                              *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************