We discussed this yesterday, and it still seems like a fine idea to me.
To add an important detail: we'd change the port from 80 to 443 for a period of, say, two weeks, without making any other changes at the same time. And then, after those two weeks, we'd starting using port 80 for the certbot challenge.
Couple quick thoughts on this plan:
Can we run a quick analysis of exit capacity to ports 80 and 443? I believe they're roughly the same, but it would be good to know.
Can we schedule this change in a way that it happens at midnight UTC, perhaps even at 2019-06-01 00:00 UTC? Just in case there is a difference in user-perceived performance, it would be easier to explain when we made this change. This could mean turning off OnionPerf instances on Friday evening and making the change on Saturday morning, just so that Friday measurements are to port 80 and Saturday measurements to port 443.
Should we try out this change at least once on a local machine, also to know exactly what configuration changes are necessary?
Changing priority to high and status to needs_review for extra visibility, in the hope that we can make this change next week. Thanks!
Trac: Cc: acute to acute, metrics-team Status: new to needs_review Priority: Medium to High
To add an important detail: we'd change the port from 80 to 443 for a period of, say, two weeks, without making any other changes at the same time. And then, after those two weeks, we'd starting using port 80 for the certbot challenge.
I think that using port 443 instead of port 80 is more representative of typical Tor traffic anyway, so even if there are large differences we would make this change.
Couple quick thoughts on this plan:
Can we run a quick analysis of exit capacity to ports 80 and 443? I believe they're roughly the same, but it would be good to know.
Do you mean exit policy? Yes, I think this is a good thing to do.
Can we schedule this change in a way that it happens at midnight UTC, perhaps even at 2019-06-01 00:00 UTC? Just in case there is a difference in user-perceived performance, it would be easier to explain when we made this change. This could mean turning off OnionPerf instances on Friday evening and making the change on Saturday morning, just so that Friday measurements are to port 80 and Saturday measurements to port 443.
To do this on Friday will be difficult as I will be in a field. Having it happen at midnight is easier and we can record the change per-instance in the metrics timeline.
Should we try out this change at least once on a local machine, also to know exactly what configuration changes are necessary?
Right now my plan is to destroy and rebuild the instances on the OTF cloud. They were managed with Salt previously but this was right at the start of when we were trying out Salt and having learned lessons from it it would be better to start again.
Initially I will change op-ab to listen on port 443 for tgen and we run this for two weeks. We can compare with the previous two weeks of op-ab data and also against the instances in the OTF cloud. Following this, I will destroy and rebuild the OTF cloud instances with tgen on port 443.
To add an important detail: we'd change the port from 80 to 443 for a period of, say, two weeks, without making any other changes at the same time. And then, after those two weeks, we'd starting using port 80 for the certbot challenge.
I think that using port 443 instead of port 80 is more representative of typical Tor traffic anyway, so even if there are large differences we would make this change.
Yes, true.
Couple quick thoughts on this plan:
Can we run a quick analysis of exit capacity to ports 80 and 443? I believe they're roughly the same, but it would be good to know.
Do you mean exit policy? Yes, I think this is a good thing to do.
I took a quick look at Onionoo output, and I didn't find that many relays that would allow port 80 and not 443. This was not a full analysis, but I'd think that we're fine here.
Can we schedule this change in a way that it happens at midnight UTC, perhaps even at 2019-06-01 00:00 UTC? Just in case there is a difference in user-perceived performance, it would be easier to explain when we made this change. This could mean turning off OnionPerf instances on Friday evening and making the change on Saturday morning, just so that Friday measurements are to port 80 and Saturday measurements to port 443.
To do this on Friday will be difficult as I will be in a field. Having it happen at midnight is easier and we can record the change per-instance in the metrics timeline.
Works for me.
Should we try out this change at least once on a local machine, also to know exactly what configuration changes are necessary?
Right now my plan is to destroy and rebuild the instances on the OTF cloud. They were managed with Salt previously but this was right at the start of when we were trying out Salt and having learned lessons from it it would be better to start again.
Initially I will change op-ab to listen on port 443 for tgen and we run this for two weeks. We can compare with the previous two weeks of op-ab data and also against the instances in the OTF cloud. Following this, I will destroy and rebuild the OTF cloud instances with tgen on port 443.