<blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">Hm. But we don't necessarily know this. Our "are we client-facing"<br>
tests are approximate, not certain, and the only way to tell whether<br>
we're intermediate or exiting is to wait and see if we're told to<br>
exit.<br></blockquote><br>Understood that client facing tests fail by design when dealing with bridges. In the case of the outbound connection component it sounds like we'll need to wait until we're either asked to extend the circuit or exit before counting it as an 'established circuit' and reporting it.<br>
<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">In fact, the leaky-pipe topology means that we're potentially<br>
intermediate _and_ exiting on a single circuit.<br></blockquote><br>(to save other readers the googling, this means that clients can exit the circuit prematurely, such as at a middle node if the exit policy permits it)<br>
<br>You're right, that would mess with the classification. If/when this is implemented I'd suggest adding anther classification for middle hops when they're first used to exit traffic.<br><br>The goal of these type flags are to indicate to controllers which circuits are sensitive and which are less so. In arm for instance most information for client/exit connections are scrubbed. Indicating via a change of the circuits status (an UPDATE event) when this begins exiting traffic seems good enough to me.<br>
<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
Also, it's still a tiny bit ambiguous: some people consider a circuit<br>
used for a rendezvous point as an exit, and some don't.<br></blockquote><br>Not following what you mean here... do you mean a hidden service rendezvous? If so then I don't see how this is exiting. Maybe the previous type classifications that simply said whether or not the inbound/outbound connection lies inside the tor network was clearer...<br>
<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">The only other change I'd suggest to xxx-circ-getinfo-option.txt is to<br>
consider using named parameters (like "WRITE=9090") rather than<br>
positional parameters<br></blockquote><br>Good idea, done (though I didn't find a good example of the preferred syntax for this).<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
Also, maybe rename the "circ" GETINFO to "rcirc" for consistency?<br></blockquote><br>Done (pity the CIRC event had already been used...).<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
There totally is a way to tell how old a descriptor is: you just look<br>
at the "published" field on the descriptor, and that tells you when it<br>
was first uploaded to the authorities.<br></blockquote><br>Sweet! Didn't realise this was available. Dropped from proposal.<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
It sounds like it should be a torrc option saying "Don't stop<br>
refetching descriptors when there's no network activity." Actually,<br>
do we have one of those already?<br></blockquote><br>Yup, we have FetchUselessDescriptors. However, setting this causes an extra load on the directory authorities, hence the desire to be able to do this a bit more selectively (for instance just fetching our own descriptor every hour but letting the rest go stale).<br>
<br>Cheers! -Damian<br><br><div class="gmail_quote">On Mon, Jun 28, 2010 at 2:59 PM, Nick Mathewson <span dir="ltr"><<a href="mailto:nickm@freehaven.net">nickm@freehaven.net</a>></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 class="im">On Thu, Jun 24, 2010 at 1:34 AM, Damian Johnson <<a href="mailto:atagar1@gmail.com">atagar1@gmail.com</a>> wrote:<br>
> Hi Nick. Thanks for the comments!<br>
><br>
>> * IN_TYPE/OUT_TYPE talk about the type of an inbound/outbound<br>
>> "connection." Do you mean circuits, or connections on the circuits?<br>
>> Either way I'm confused. For example, a control connection is never<br>
>> attached to a circuit at all.<br>
><br>
> Yea, that isn't really appropriate and was making the spec messier than it<br>
> needed to be. Replaced with a single TYPE parameter to indicate the<br>
> placement in the circuit (guard/bridge, relay, exit, or one-hop in case<br>
> they're allowing them).<br>
<br>
</div>Hm. But we don't necessarily know this. Our "are we client-facing"<br>
tests are approximate, not certain, and the only way to tell whether<br>
we're intermediate or exiting is to wait and see if we're told to<br>
exit. In fact, the leaky-pipe topology means that we're potentially<br>
intermediate _and_ exiting on a single circuit.<br>
<br>
Also, it's still a tiny bit ambiguous: some people consider a circuit<br>
used for a rendezvous point as an exit, and some don't.<br>
<br>
The only other change I'd suggest to xxx-circ-getinfo-option.txt is to<br>
consider using named parameters (like "WRITE=9090") rather than<br>
positional parameters ('The third value is the write one'). This has<br>
turned out to make it way easier to expand events in the future.<br>
(Consider what would happen if we wanted to add another field to<br>
RCIRC.)<br>
<br>
Also, maybe rename the "circ" GETINFO to "rcirc" for consistency?<br>
<div class="im"><br>
On xxx-getinfo-option-expansion.txt :<br>
<br>
</div><div class="im">>> * On "desc/time", why is it important to know the latest time we<br>
>> fetched a server descriptor?<br>
><br>
> There's some interesting information here such as your relay's observed<br>
> bandwidth. However, there's no way of telling how stale information provided<br>
> by the "desc/id/*" is, and since most relays stop fetching descriptors after<br>
> a time it's often hideously ancient.<br>
<br>
</div>There totally is a way to tell how old a descriptor is: you just look<br>
at the "published" field on the descriptor, and that tells you when it<br>
was first uploaded to the authorities.<br>
<br>
If it's important to tell when you _fetched_ the descriptor (as<br>
opposed to when it was first published), we do store that information,<br>
but it should be made available on a per-descriptor basis, right?<br>
That would be more useful.<br>
<div class="im"><br>
> What I'd really like an option to manually refresh descriptors (both<br>
> individually and as a batch call), however since I was aiming to keep this<br>
> proposal limited to GETINFO options it seemed inappropriate. Do you have any<br>
> thoughts on this sort of functionality? What section of the control-spec<br>
> would it go under?<br>
<br>
</div>It sounds like it should be a torrc option saying "Don't stop<br>
refetching descriptors when there's no network activity." Actually,<br>
do we have one of those already?<br>
<div class="im"><br>
>> * Also on process/user: If you meant "username", then there should<br>
>> indeed be an option to get all the *id stuff discussed upthread.<br>
><br>
> I'm sure this is a dumb question but... why? I've never had use for the<br>
> numeric uid, let alone the three other varieties Jake mentioned (actually,<br>
> never heard of them before...). If you can think of use cases in which<br>
> they're useful then by all means include them. However, I don't particularly<br>
> care about that information.<br>
<br>
</div>For unixy programs, it's way easier to work with uids than with<br>
usernames. The other varieties are useful for telling you about Tor's<br>
setuid/setgid state.<br>
<br>
Other than that, looks good.<br>
--<br>
<font color="#888888">Nick<br>
</font></blockquote></div><br>