[metrics-team] onionoo exit_addresses semantics

[Karsten Loesing]

On 2018-02-17 01:33, teor wrote:
> 
> On 17 Feb 2018, at 11:05, nusenu <nusenu-lists at riseup.net> wrote:
> 
>>> On 17 Feb 2018, at 09:30, nusenu <nusenu-lists at riseup.net> wrote:
>>>
>>>>>> 1. Stop deduplicating exit addresses and just include everything from
>>>>>> exit lists found in the past 24 hours. Would this help?
>>>>>
>>>>> This would be more accurate for my exit, which does not ever exit on
>>>>> its ORPort address.
>>>>
>>>> Why would that be more accurate? (it would not actually change exit_addresses
>>>> compared to the current state if it never exits on the ORPort, right?)
>>>
>>> The current format does not distinguish between:
>>> * an exit that exits on its ORPort address and another address
>>> * an exit that only exits on another address
>>
>> Ok, I think I got your point now, it would not change your exit's exit_addresses
>> field but it would result in a change for other exit relays that exited via their 
>> ORPort IP _and_ some other address (within the last 24 hours) - and the fact that 
>> it does _not_ include the OR IP would actually mean something (because currently
>> there is not way it would be included).
>>
>> I would still omit that field if ORPort IP would be the _only_ member in the exit_addresses 
>> array because it increases size without increasing information.
> 
> That's true, but it also increases client code complexity, because a user has to
> write something like:
> 
> Set actual exit addresses to exit addresses
> 
> if exit policy is not reject all IPv4 and exit addresses field is blank:
>   Add ORPort IPv4 addresses to actual exit addresses
> 
> if exit policy is not reject all IPv6 and exit addresses field is blank:
>   Add ORPort IPv6 addresses to actual exit addresses
> 
> Use actual exit addresses
> 
> Do we think users will understand the definition of exit addresses, and
> write correct code like this every time?
> 
> It might be worth the extra data. Compression should reduce the extra
> network bandwidth.

Let's include the extra data if it helps reduce confusions like this in
the future.

I'll leave this thread here for the weekend, in case somebody has even
better ideas what to do. And if not, I'll open a ticket next week to
make this change.

Thanks!

All the best,
Karsten


> 
> T
> _______________________________________________
> metrics-team mailing list
> metrics-team at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 528 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/metrics-team/attachments/20180217/9c3a666b/attachment-0001.sig>