Hi tor-dev@ mailing list,
I have Proposal 299, also known as "Preferring IPv4 or IPv6 based on IP Version Failure Count" which makes ClientAutoIPv6ORPort take into account IPv4 and IPv6 failures.
An older version of this document is available here: https://gitweb.torproject.org/torspec.git/tree/proposals/299-ip-failure-coun...
I have attached an updated copy of this proposal to this message. This includes the changes recommended by teor at https://lists.torproject.org/pipermail/tor-dev/2019-February/013673.html.
Would someone be able to update torspec to include the updated (and attached) proposal?
Also, if any of you have opinions on this proposal, please share them with me.
-Neel
===
On 5 Mar 2019, at 02:24, Neel Chauhan neel@neelc.org wrote:
Hi tor-dev@ mailing list,
I have Proposal 299, also known as "Preferring IPv4 or IPv6 based on IP Version Failure Count" which makes ClientAutoIPv6ORPort take into account IPv4 and IPv6 failures.
An older version of this document is available here: https://gitweb.torproject.org/torspec.git/tree/proposals/299-ip-failure-coun...
I have attached an updated copy of this proposal to this message. This includes the changes recommended by teor at https://lists.torproject.org/pipermail/tor-dev/2019-February/013673.html.
Would someone be able to update torspec to include the updated (and attached) proposal?
Sure. We usually do torspec changes using GitHub pull requests. Can you open a pull request on https://github.com/torproject/torspec ? Then link to the pull request from #27491 or in an email reply.
Also, if any of you have opinions on this proposal, please share them with me.
Just so you know:
Tor Browser is going to test the #27940 version of ClientAutoIPv6ORPort in their alpha series, as a potential fix for IPv6 failures: https://trac.torproject.org/projects/tor/ticket/29641#comment:4
I expect that #27940 will trigger some bugs in the guard code, because all connections for an entire IP version will fail. Then we can teach the guard code to ignore those kinds of failures.
But that will mean that Tor Browser is depending on ClientAutoIPv6ORPort. So we will also need to add a new option to activate the code for this proposal. (Otherwise, we won't know if this proposal is better or worse!)
Here's one way we could do that:
Add a new option ClientAutoIPv6ORPortStrategy, which takes some flags. When no flags are set (the default), we use the original ClientAutoIPv6ORPort. Then we add a flag for this proposal: - TrackFailures
Then other tickets can use other flags: - CheckLocalAddresses for #27492 Try IPv4 or IPv6 more often based on public or private IP addresses - CheckConsensus for #27647 When randomly choosing IPv4 or IPv6, set IPv6 probability based on IPv6 weight
What do you think? Would you like to make these changes to this proposal?
T
Hi teor,
On 2019-03-05 21:12, teor wrote:
Sure. We usually do torspec changes using GitHub pull requests. Can you open a pull request on https://github.com/torproject/torspec ? Then link to the pull request from #27491 or in an email reply.
The GitHub PR is here: https://github.com/torproject/torspec/pull/61
Just so you know:
Tor Browser is going to test the #27940 version of ClientAutoIPv6ORPort in their alpha series, as a potential fix for IPv6 failures: https://trac.torproject.org/projects/tor/ticket/29641#comment:4
I expect that #27940 will trigger some bugs in the guard code, because all connections for an entire IP version will fail. Then we can teach the guard code to ignore those kinds of failures.
But that will mean that Tor Browser is depending on ClientAutoIPv6ORPort. So we will also need to add a new option to activate the code for this proposal. (Otherwise, we won't know if this proposal is better or worse!)
Makes sense. After all, IPv4/IPv6 selection is complex it something this complicated shouldn't be a "one size fits all".
Here's one way we could do that:
Add a new option ClientAutoIPv6ORPortStrategy, which takes some flags. When no flags are set (the default), we use the original ClientAutoIPv6ORPort. Then we add a flag for this proposal:
- TrackFailures
Then other tickets can use other flags:
- CheckLocalAddresses for #27492 Try IPv4 or IPv6 more often based on public or private IP
addresses
- CheckConsensus for #27647 When randomly choosing IPv4 or IPv6, set IPv6 probability
based on IPv6 weight
What do you think? Would you like to make these changes to this proposal?
These additions sound good.
I have added the "TrackFailures" flag to my GitHub PR and also mentioned other flags will come in the future.
-Neel
===
On 7 Mar 2019, at 09:07, Neel Chauhan neel@neelc.org wrote:
Hi teor,
On 2019-03-05 21:12, teor wrote:
Sure. We usually do torspec changes using GitHub pull requests. Can you open a pull request on https://github.com/torproject/torspec ? Then link to the pull request from #27491 or in an email reply.
The GitHub PR is here: https://github.com/torproject/torspec/pull/61
Thanks, I opened a ticket to review and merge it here: https://trac.torproject.org/projects/tor/ticket/29687
It should get reviewed within a week or two.
Here's one way we could do that: Add a new option ClientAutoIPv6ORPortStrategy, which takes some flags. When no flags are set (the default), we use the original ClientAutoIPv6ORPort. Then we add a flag for this proposal:
- TrackFailures
Then other tickets can use other flags:
- CheckLocalAddresses for #27492 Try IPv4 or IPv6 more often based on public or private IP
addresses
- CheckConsensus for #27647 When randomly choosing IPv4 or IPv6, set IPv6 probability
based on IPv6 weight What do you think? Would you like to make these changes to this proposal?
These additions sound good.
I have added the "TrackFailures" flag to my GitHub PR and also mentioned other flags will come in the future.
I like what you did here: I think having one option with extra flags is better than two options.
T
Hi teor,
Thanks, I opened a ticket to review and merge it here: https://trac.torproject.org/projects/tor/ticket/29687
It should get reviewed within a week or two.
First off, thank you for doing this! As of now, it seems to have been merged.
I have added the "TrackFailures" flag to my GitHub PR and also mentioned other flags will come in the future.
I like what you did here: I think having one option with extra flags is better than two options.
Again, Thank you!
Also, can we mark Prop299 as "Accepted" or is there any updates needed to this proposal?
-Neel
===
On 13 Mar 2019, at 08:44, Neel Chauhan neel@neelc.org wrote:
Hi teor,
Thanks, I opened a ticket to review and merge it here: https://trac.torproject.org/projects/tor/ticket/29687 It should get reviewed within a week or two.
First off, thank you for doing this! As of now, it seems to have been merged.
I have added the "TrackFailures" flag to my GitHub PR and also mentioned other flags will come in the future.
I like what you did here: I think having one option with extra flags is better than two options.
Again, Thank you!
Also, can we mark Prop299 as "Accepted" or is there any updates needed to this proposal?
I haven't reviewed the latest version, and I'm not sure if anyone else has either. (I was hoping that someone else would review your latest version before it got merged.)
Reading through it, I've noticed some things that I don't understand. I'll do a review on your pull request. I'll also get a second team member to review the proposal.
T
-
Neel Chauhan -
teor