availability-recovery: bump chunk fetch threshold to 1MB for Polkadot and 4MB for Kusama + testnets

[sandreim]

Doing this change ensures that we minimize the CPU usage we spend in reed-solomon by only doing the re-encoding into chunks if PoV size is less than 4MB (which means all PoVs right now)

Based on susbystem benchmark results we concluded that it is safe to bump this number higher. At worst case scenario the network pressure for a backing group of 5 is around 25% of the network bandwidth in hw specs.

Assuming 6s block times (max_candidate_depth 3) and needed_approvals 30 the amount of bandwidth usage of a backing group used would hover above 30 * 4 * 3 = 360MB per relay chain block. Given a backing group of 5 that gives 72MB per block per validator -> 12 MB/s.

Reality check on Kusama PoV sizes (click for chart)

[ordian]

Based on susbystem benchmark results we concluded that it is safe to bump this number higher. At worst case scenario the network pressure for a backing group of 5 is around 25% of the network bandwidth in hw specs.

Currently, the network up(load) requirements are quite low in this regard and making everyone download from backers in all the cases would change that quite a bit (+160MBit/s with backing group size of 3 assuming all 3 have the PoV and not just 2). I would also like to see this tested in the presence of disputes, when every paravalidator needs to download the PoV, not just 30.

To be on the safer side, would it be possible to gate this change to be Kusama only? Or start with a lower limit, e.g. 1MB.

[sandreim]

Based on susbystem benchmark results we concluded that it is safe to bump this number higher. At worst case scenario the network pressure for a backing group of 5 is around 25% of the network bandwidth in hw specs.

Currently, the network up(load) requirements are quite low in this regard and making everyone download from backers

Is this asymmetric upload/download specs documented anywhere. The specs I am looking at say:

The minimum symmetric networking speed is set to 500 Mbit/s (= 62.5 MB/s). This is required to support a large number of parachains and allow for proper congestion control in busy network situations.

in all the cases would change that quite a bit (+160MBit/s with backing group size of 3 assuming all 3 have the PoV and not just 2). I would also like to see this tested in the presence of disputes, when every paravalidator needs to download the PoV, not just 30.

Yeah, with a backing group of 3, the load in worst case is 50% of this network bandwidth. However in the case of disputes the backers would be hammered, so the download of the PoV will fallback to chunks so we should be fine as this is an exceptional situation. We can definitely try this scenario with subsystem benchmarks, or are you suggesting we do a Versi test ?

To be on the safer side, would it be possible to gate this change to be Kusama only? Or start with a lower limit, e.g. 1MB.

This is doable per chain. I'd go for that rather than 1MB.

[burdges]

However in the case of disputes the backers would be hammered

Yes, we're worried about variance here, since the averages stay the same. We'll presumably need the tit-for-tat game in availability rewards eventually, since you'd save lots by just not helping others check.

[sandreim]

Switched to 1MB ok Polkadot and 4MB on Kusama + all testnets. @ordian PTAL.

[paritytech-cicd-pr]

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-clippy
Logs: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/6281150

[alindima]

Looks reasonable! Don't forget to update the PR description and title (will be used for commit message and they're outdated)