Incoporate notification of rate limiting in conference checklist #751
Comments
|
We never get the public IPv4 address before Monday.
IPv6 is a non-issue as they don’t seem to rate-limit on the /48, but on the /128.
Since every host gets an individual IPv6 address, there’s a unique /128 per device.
Owen
… On Mar 22, 2024, at 12:48, Robert James Hernandez ***@***.***> wrote:
Description
Update docs/conference checklist: https://docs.google.com/document/d/1bIdJmbOmKFKKf7YQjrVjy0aw3g8ajMC8krswPXb-GyM/edit?usp=sharing
The goal is to lessen the potential of attendees being rate limited while at the conference.
The following potential rate limit providers that should be contacted prior to the conference starting with our public IPv4 address and IPv6 subnet:
GitHub
Docker
Fastly (they front cache.nixpkgs.org and seemed to slow us down at one point in both the conference center and hotel)
Additionally it would be a good idea to have user workarounds: Auth Token, etc.
Acceptance Criteria
Documentation in conf checklist for providers that could rate limit attendees
Documentation for workarounds to rate limits imposed by providers
—
Reply to this email directly, view it on GitHub <#751>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAK6GTWUKPV424IQPFA2JJDYZSDHNAVCNFSM6AAAAABFD4TPRCVHI2DSMVQWIX3LMV43ASLTON2WKOZSGIYDGMRQGIZTINA>.
You are receiving this because you are subscribed to this thread.
|
Yep thats why its in the conference instead of preconf checklist
Thats good to know, I figured we could cover our basis on ipv6 just so each provider has that information. |
Do you know why this is @owendelong? |
PCC and company allocate the ipv4 address off their existing router when we show up on monday. Even if we got it ahead of time I wouldnt surprise me that its subject to change |
|
Seems odd they wouldn't know that address well in advance as I seriously doubt it changes... maybe I'm over thinking it though |
|
It does. They’ve changed ISPs at least 3 times in the time we’ve been holding our event there. Prior to this year, we were getting a /29 from them. This year, we got a single /32.
It appears that they have reduced their overall range from it’s previous /26 to now being just a /29 for the entire PCC.
I won’t defend or even attempt to explain their conduct, but Encore does what Encore does and we just have to cope with it as best we can.
… On Mar 23, 2024, at 18:41, Gene Liverman ***@***.***> wrote:
Seems odd they wouldn't know that address well in advance as I seriously doubt it changes... maybe I'm over thinking it though
—
Reply to this email directly, view it on GitHub <#751 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAK6GTTFUZLFEDHM2ACLNPLYZYVMXAVCNFSM6AAAAABFD4TPRCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWGY2TQNZVGI>.
You are receiving this because you were mentioned.
|
|
We reduced to a /32 because we said we didn't need more than 1 IP and it allowed significant savings. |
|
Is the significant savings worth the blowback from the rate limiting? Owen is against running a NAT pool on the firewalls, but it could make it less of an issue, if for example we had two IPs (one for each building). @sarcasticadmin I have a few contacts at Fastly that I can poke, to see if they're willing to make some exceptions, can't make any promises though. |
|
Given we paid many many thousands of dollars per year for 5+ years for the extra IPs and never used them, yes its worth the savings. |
|
On Thu, 28 Mar 2024, Ryan Hamel wrote:
Is the significant savings worth the blowback from the rate limiting? Owen is
against running a NAT pool on the firewalls, but it **could** make it **less**
of an issue, if for example we had two IPs (one for each building).
I would prefer not to break sessions when people move from one building to the
other.
David Lang
|
@MrHamel considering we got rate limited in < 1hr on Thursday I dont see there being much benefit to having a few more IPs since it doesnt by us much additional overhead for the number of requests.
👍 thatd be much appreciated |
@davidelang the address space between the buildings for wireless is already different: scale-network/switch-configuration/config/vlans.d/Expo Lines 2 to 3 in c6e657d scale-network/switch-configuration/config/vlans.d/Conference Lines 2 to 3 in c6e657d |
|
On Fri, 29 Mar 2024, Robert James Hernandez wrote:
> I would prefer not to break sessions when people move from one building to the
other.
@davidelang the address space between the buildings for wireless is already different: https://github.com/socallinuxexpo/scale-network/blob/c6e657d6cca7fc17aac370905dd1e8105d087f8b/switch-configuration/config/vlans.d/Expo#L2-L3
yep, realized that just after I sent the message, sorry.
David Lang
|
|
Actually, we did use them. We made changes this year to reduce our IPv4 utilization and we also had used them previously some years for an Akamai cache server. We don’t need them any more, but it is not far to say we did not use them. This year is also the first time you mentioned that the multiple IPv4 addresses were costing us extra. OwenOn Mar 29, 2024, at 05:32, Ilan Rabinovitch ***@***.***> wrote:
Given we paid many many thousands of dollars per year for 5+ years for the extra IPs and never used them, yes its worth the savings.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
On Mar 29, 2024, at 09:57, David Lang ***@***.***> wrote:
On Thu, 28 Mar 2024, Ryan Hamel wrote:
Is the significant savings worth the blowback from the rate limiting? Owen is
against running a NAT pool on the firewalls, but it **could** make it **less**
of an issue, if for example we had two IPs (one for each building).
I would prefer not to break sessions when people move from one building to the
other.
They break anyway because their internal address will change. I don’t see a significant gain to doing separate addresses per building because the rate limiting was mostly workshop related which meant it was mostly in one building anyway.
David Lang
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Description
Update docs/conference checklist: https://docs.google.com/document/d/1bIdJmbOmKFKKf7YQjrVjy0aw3g8ajMC8krswPXb-GyM/edit?usp=sharing
The goal is to lessen the potential of attendees being rate limited while at the conference.
The following potential rate limit providers that should be contacted prior to the conference starting with our public IPv4 address and IPv6 subnet:
Additionally it would be a good idea to have user workarounds: Auth Token, etc.
Acceptance Criteria
The text was updated successfully, but these errors were encountered: