Add temporary environment variables for controlling percentage of traffic to E-IPFS

[kylehuntsman]

Saturn is looking to gradually increase traffic to E-IPFS providers. We currently only support excluding providers 100%. We could build temporary E-IPFS specific dials to control traffic. Providing environment variables for dialing traffic will make future updates increasing or decreasing traffic easier for the Saturn team, as opposed to hard coding values and requiring a Lassie release each time.

New Environment Variables

• LASSIE_EIPFS_PROVIDERS: A comma delimited list of known E-IPFS peer IDs
• LASSIE_EIPFS_TRAFFIC_PERCENTAGE: An integer from 0-100 describing the percentage of traffic that reaches out to EIPFS providers.
  • Example: a value of 25 will let Lassie reach out to EIPFS providers 25 times out of every 100 occurances of an EIPFS candidate lookup.

2023-04-27 EDIT: Callout that this solution is a temporary short term solution to support troubleshooting

[rvagg]

we could just add one additional var: LASSIE_EXCLUDE_PROVIDERS_PERCENTAGE that defaults to 100 but can be lowered, so it works on the existing LASSIE_EXCLUDE_PROVIDERS and isn't EIPFS specific (although we know this is only going to be used for that case, but it's nice to pretend to be generic at least!)

[gruns]

awesome @kylehuntsman 🙌. thank you for this issue! 👏

@rvagg i like the thought of generalizing, but traffic passthrough percentages will/would likely differ by provider right? eg we may want LASSIE_EIPFS_TRAFFIC_PERCENTAG=25 and LASSIE_SP_TRAFFIC_PERCENTAGE=10, so one LASSIE_EXCLUDE_PROVIDERS_PERCENTAGE may not even be what we want

thus, my 👍 vote is to just use LASSIE_EIPFS_TRAFFIC_PERCENTAGE for now and only generalize if/when demonstrably useful. right now LASSIE_EXCLUDE_PROVIDERS_PERCENTAGE would only be more confusing/less specific

[kylehuntsman]

Thank you @gruns for your input!

After discussing with @rvagg in our standup earlier, I think we prefer a generic approach. Our consensus with Lassie has been to try and be as general as possible in an attempt to avoid favoring specific vendors and potentially narrowing the scope of Lassie as a general purpose tool for enabling easy retrievals in other applications.

I originally suggested the additional environment variables to keep the 100% excluded providers and the percentage traffic provider functionality separate. However, because we know that Saturn is currently only excluding the EIPFS providers and that the percentage traffic is meant to be a short term solution while we troubleshoot, I think the general solution provided by @rvagg is sufficient.

I might feel differently about making this general if we felt we were going to limit EIPFS traffic for longer than required to troublshoot the current amplification problem. We could always be specific later if required, but I would prefer we favor the generic case first.

I think the idea is we'll rip this out the moment we allow 100% of the EIPFS traffic to flow to them.

[willscott]

• we can potentially validate the amplification characteristics using just this control
• it would be preferable if we could do it via segmentation of traffic streams - if we could enable based on the blockLimit that would be ideal
  • in particular, the requests we're most concerned with will have blockLimit=10 while the other segment will be for car files and will not have block limit set.

[rvagg]

@willscott do we have enough control upstream to be able to couple &blockLimit= with other parameters? i.e. could we add query parameters to do this work too?

We could probably hack together a quick language to do this kind of thing, along with segmenting. e.g.

LASSIE_TRAFFIC_PERCENTAGE= or ?trafficPercentage= with a value graphsync:10,QmcCtpf7ERQWyvDT8RMYWCMjzE74b7HscB3F8gDp5d5yS6:0 - might say "10% dice-roll chance of including graphsync in the transport for a request and 0% chance of including peer ID QmcCtpf7ERQWyvDT8RMYWCMjzE74b7HscB3F8gDp5d5yS6 in a request".

So the parsing rule would be something like: graphsync, bitswap, http are fixed protocol strings, otherwise attempt to parse a PeerID. Comma separated list where there's one of these strings as a prefix, a : and a suffix that has the percentage as an integer. The percentage controls the dice-roll chance of any request including that protocol/peer if it has candidates.

Tying it to blockLimit seems like more of a leap, but if upstream controls blockLimit then perhaps it could also just pass in another query parameter that overrides any LASSIE_TRAFFIC_PERCENTAGE value that's currently set.

[willscott]

we can pass in a query parameter and do this decision in the L1 javascript if that's preferable. this is really just for running a couple segmentation experiments over the next week, so it's going to be a bit hacky and eventually removable in either case.