[metrics-team] onionoo exit_addresses semantics

[Karsten Loesing]

On 2018-02-17 11:18, nusenu wrote:
> 
> 
> teor:
>>
>> 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.
> 
> I my case it is just the other way around, if onionoo will include the 
> data I'll have to do what onionoo does for me now (deduplication).

Ah, so would that be an issue for you? I believe we'd have to make a
major protocol version bump for this change anyway, so you'd have at
least 1 month early warning.

Also, we can still decide whether to change the code or clarify the
specification.

All the best,
Karsten




>  
> 
> 
> 
> _______________________________________________
> 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/e8962766/attachment.sig>