3rd Community Review of BDX Allocator

[cryptoAmandaL]

First Review #20
Second Review #142

Latest Allocator Compliance Review https://compliance.allocator.tech/report/f03018484/1728866648/report.md

Given 2.5PiBs
DataCap was given to:
cryptoAmandaL/BDE-Allocator#22 (2PiB)
cryptoAmandaL/BDE-Allocator#8 (0.5PiB)

#22
After KYC and the first round allocation, we found the retrieval success rate to be poor.

Then we have communicated with clients on this issue and get a response from this client. We decided to give him a chance to wait for sps' improvement.

When cid bot showed that client use more than 75% datacap, I got a new report.

Compared with two results in reports, we've seen a significant increase in the success rate of sps' retrieval. So we decided to give them a new round of allocation.

#8

Compared with two results in reports, the retrieval success rate is decreasing. Client's sps are currently not capable of improving retrieval rates in a short time. So we closed this application and stop the work with this client.

[filecoin-watchdog]

@cryptoAmandaL
Allocator Application
Compliance Report
First Review
Second Review

1st Review score: 2.5PiB granted
2nd Review score: 2.5PiB granted

0.5 PiB granted to existing clients:

Existing Client Name	DC
NHGRI	0.5 PiB

2 PiB granted to new clients:

New Client Name	DC
ESGFand Pangeo	2 PiB

Example 1 - issue 8
The allocator has only allocated one allocation (512TiB) to this client since the last DC refresh, the client has not shown any improvement, so the allocator has closed the application.

I would like to point out, however, that the 3 previous CID reports were rather bad and the allocation of 512TiB seems to be unjustified.

Additionally, this dataset has already appeared multiple times in filecoin. The allocator should have checked and clarified these issues before granting the first allocation:

• https://github.com/search?q=repo%3Afilecoin-project%2Ffilecoin-plus-large-datasets+encode-public&type=issues
• [DataCap Application] <Socyber> - <Encode> Carohere/Caro-Allocator#14
• [DataCap Application] AWS-ENCODE luhong123/QC-Data-center#11

Example 2 - issue 22
The client requested 5 PiB and declared 7 data replicas of 1792TiB each. With this dataset size, a minimum of 12 PiB of data should be requested. It wasn’t raised by the allocator.

The dataset was stored multiple times:

• https://github.com/search?q=repo%3Afilecoin-project%2Ffilecoin-plus-large-datasets+cmip6-pds&type=issues
• [DataCap Application] Coupled Model Intercomparison Project 6 Carohere/Caro-Allocator#8
• [DataCap Application] <Coupled Model Intercomparison Project 6> Storify-LLC/Storify-Data-Pathway#14

SPs provided:
f02169597 Shenzhen
f02365890 Hongkong
f0509981 Guizhou
f01844118 Newyork
f02834511 Hongkong

SPs Updated in the issue:	1st CID	2nd CID
f03099988 HongKong	0.00	0
f01084941 HongKong	0.00	5.35
f03100001 Shenzhen	0.05	0.04
f02046115 USA (actually HK)	0.00	0
f03030649 China	-	65.38
f03156722 HongKong	-	98.88
f03100003 Shenzhen	0.04	0.07

Additional SPs used for deals:
f03100009 HK 0.00
f01975299 CN 0.00
f03100002 CN 0.05
f03100000 CN 0.07
f01084413 CN 90.91
f03214920 HK 0.00

The client updated the SP list after receiving the DC, so the SP list used for deals does not match the SP list provided in the form.

• The first CID report showed that all seven SPs have retrieval rates below 1% or do not support spark. The allocator commented that this should be fixed, but granted another tranche.

• The next report showed 6 additional SPs, about which the client did not inform the allocator via github issue. Only 1 SP has retrieval at a satisfactory level, while the rest are around 0.

• Compared with two results in reports, we've seen a significant increase in the success rate of sps' retrieval. So we decided to give them a new round of allocation.

After the second tranche, only 2 SPs improved their results significantly, but the allocator considered that the results improved and that cooperation could continue. Considering the allocator's comment and report analysis, I don't understand where the significant increase was observed.

• The last report shows that 5 out of 13 SPs have retrieval rates at a satisfactory level; 1 has retrieval around 30%, and the rest are 0%.
• The client declared 7 replicas, but according to the report, there are 16 of them already.
• The client declared that one of the SPs is from the US; according to the report, it is an SP from Hong Kong (f02046115). Suspected use of VPN.
• The allocator declared in its application that it will require 4 geopolitical regions and 5 physical locations, but in the case of this application, the SPs come only from Hong Kong or China.