Hi, I&#39;ve made another addition to the get-info proposal for a piece of information Sebastian pointed out at the tor dev meeting. It consists of a GETINFO option and corresponding events for daily aggregated statistics for the ports we&#39;re exiting to (only for exit relays). This would use the feature we already have for the torrc option:<br>
<br>ExitPortStatistics<br>When this option is enabled, Tor writes statistics on the number of relayed bytes and<br>opened stream per exit port to disk every 24 hours. Cannot be changed while Tor is<br>running. (Default: 0)<br>
<br>Cheers! -Damian<br><br><div class="gmail_quote">On Sat, Jul 10, 2010 at 2:43 PM, Damian Johnson <span dir="ltr">&lt;<a href="mailto:atagar1@gmail.com">atagar1@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">Here&#39;s an alternate proposal...<br></blockquote><br>Yup, that removes a lot of ambiguity and works perfectly for this purpose so changed. Thanks!<div class="im">
<br>

<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">But fetching our own descriptor is kind of needless; we generated it<br>
ourself, after all.  Is it not accessible via the control port?  We do<br>
*have* it; it&#39;s a static variable in router.c.  What am I missing?<br></blockquote><br></div>I&#39;m not aware of it being available via GETINFO with the exception of running:<br>&quot;desc/id/&lt;my fingerprint&gt;&quot;<br>


which I&#39;m assuming means we get a stale version of our own descriptor if not fetching new descriptors.<br><br>Regardless, lets drop any addition concerning descriptors. With the addition of micro-descriptors any usage I have for them will soon be irrelevant. Currently I&#39;m just using descriptors for two purposes:<br>

<br>- Our own descriptor for the observed bandwidth if...<br>    ... our tor version is too old, lacking consensus entries with the measured bandwidth (a more meaningful stat)<br>    ... or to figure out what the measured bandwidth stat represents. This usage is just a hack and will go away with: <a href="https://trac.torproject.org/projects/tor/ticket/1690" target="_blank">https://trac.torproject.org/projects/tor/ticket/1690</a><br>

<br>- Descriptors of other relays for the exit policy, platform, and tor version. Micro descriptors are providing the first of these and the rest are hardly worth downloading the descriptors unless specifically requested.<br>

<br>In other words I&#39;ll soon drop usage of descriptors except for fallback behavior in old tor versions... for which any new GETINFO options are useless anyways ;)<br><br>Cheers! -Damian<div><div></div><div class="h5">
<br><br><div class="gmail_quote">
On Fri, Jul 9, 2010 at 6:38 PM, Nick Mathewson <span dir="ltr">&lt;<a href="mailto:nickm@freehaven.net" target="_blank">nickm@freehaven.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


<div>On Tue, Jun 29, 2010 at 11:00 AM, Damian Johnson &lt;<a href="mailto:atagar1@gmail.com" target="_blank">atagar1@gmail.com</a>&gt; wrote:<br>
&gt;&gt; Hm.  But we don&#39;t necessarily know this.  Our &quot;are we client-facing&quot;<br>
&gt;&gt; tests are approximate, not certain, and the only way to tell whether<br>
&gt;&gt; we&#39;re intermediate or exiting is to wait and see if we&#39;re told to<br>
&gt;&gt; exit.<br>
&gt;<br>
&gt; Understood that client facing tests fail by design when dealing with<br>
&gt; bridges. In the case of the outbound connection component it sounds like<br>
&gt; we&#39;ll need to wait until we&#39;re either asked to extend the circuit or exit<br>
&gt; before counting it as an &#39;established circuit&#39; and reporting it.<br>
<br>
</div>Or we could drop the false notion that &quot;middle&quot; or &quot;exit&quot; or &quot;entry&quot;<br>
make a partition of established relay or_circuits.   (They aren&#39;t a<br>
partition because: first, they don&#39;t cover or_circuits.  A circuit<br>
that has been just extended to us can&#39;t be called a middle or an exit.<br>
 Second, they aren&#39;t exclusive: a circuit that has been extended from<br>
us and used as an exit can be called both a middle _and_ an exit.)<br>
See below for another possibility.<br>
<div><br>
&gt;&gt; In fact, the leaky-pipe topology means that we&#39;re potentially<br>
&gt;&gt; intermediate _and_ exiting on a single circuit.<br>
&gt;<br>
&gt; (to save other readers the googling, this means that clients can exit the<br>
&gt; circuit prematurely, such as at a middle node if the exit policy permits it)<br>
&gt;<br>
&gt; You&#39;re right, that would mess with the classification. If/when this is<br>
&gt; implemented I&#39;d suggest adding anther classification for middle hops when<br>
&gt; they&#39;re first used to exit traffic.<br>
<br>
</div>It *IS* implemented server-side.  The clients just don&#39;t use it.<br>
<br>
(Since the point of this design is to safely expose accurate circuit<br>
status info via the control port, we might as well try to expose the<br>
possible states of current circuits, including states that don&#39;t<br>
typically occur.  Otherwise, if some future weird client started using<br>
them, you&#39;d need to upgrade Tor *and* arm to get an accurate report.)<br>
<div><br>
&gt; The goal of these type flags are to indicate to controllers which circuits<br>
&gt; are sensitive and which are less so. In arm for instance most information<br>
&gt; for client/exit connections are scrubbed. Indicating via a change of the<br>
&gt; circuits status (an UPDATE event) when this begins exiting traffic seems<br>
&gt; good enough to me.<br>
<br>
</div>Here&#39;s an alternate proposal.  The idea of type flags is good, but<br>
instead of the ones in your proposal, let&#39;s only use circuit type<br>
flags that have an unambiguous meaning from the point of view of Tor&#39;s<br>
spec and implementation.<br>
<br>
For instance,<br>
   (E)ntry : a connection from a node that doesn&#39;t appear to be a Tor server.<br>
   E(X)it : has been used for at least one exit stream<br>
   (R)elay : has been extended.<br>
   Rende(Z)vous : is being used for a rendezvous point<br>
   (I)ntroduction : is being used for a hidden service introduction<br>
   (N)one of the above: none of the above have happened yet.<br>
<br>
These all have nice, clear-cut, easy-to-evaluate meanings, some of<br>
which are mutually exclusive, and some of which aren&#39;t.<br>
<br>
 [...]<br>
<div>&gt;&gt; It sounds like it should be a torrc option saying &quot;Don&#39;t stop<br>
&gt;&gt; refetching descriptors when there&#39;s no network activity.&quot;  Actually,<br>
&gt;&gt; do we have one of those already?<br>
&gt;<br>
&gt; Yup, we have FetchUselessDescriptors. However, setting this causes an extra<br>
&gt; load on the directory authorities, hence the desire to be able to do this a<br>
&gt; bit more selectively (for instance just fetching our own descriptor every<br>
&gt; hour but letting the rest go stale).<br>
<br>
</div>But fetching our own descriptor is kind of needless; we generated it<br>
ourself, after all.  Is it not accessible via the control port?  We do<br>
*have* it; it&#39;s a static variable in router.c.  What am I missing?<br>
<br>
yrs,<br>
--<br>
<font color="#888888">Nick<br>
</font></blockquote></div><br>
</div></div></blockquote></div><br>