584 -> 0584

neps/nep-584.md → neps/nep-0584.md

@@ -138,7 +138,7 @@ The flow will look like this:
 - The chunk is applied and produces outgoing receipts, receipts are sent until they hit the limits
   set by `BandwidthScheduler`.
 
-![Diagram where bandwidth scheduler requests bandwidth and then sends receipts](assets/nep-584/basic-flow.png)
+![Diagram where bandwidth scheduler requests bandwidth and then sends receipts](assets/nep-0584/basic-flow.png)
 
 Details will be explained in the following sections.
 
@@ -679,7 +679,7 @@ Every link has some allowance, in this example let's say that all links start wi
 All shards start with sender and receiver budgets set to `max_shard_bandwidth` (4.5MB). Budgets
 describe how much more a shard can send or receive:
 
-![State of links before scheduler runs](assets/nep-584/scheduler_example_1.png)
+![State of links before scheduler runs](assets/nep-0584/scheduler_example_1.png)
 
 First step of the algorithm is to give out a fair share of allowance on every link.
 In an ideally fair world every link would send the same amount of data at every height, so the fair share of allowance is:
@@ -698,7 +698,7 @@ So every link receives `1.5MB` of allowance. But allowance can't get larger than
 
 The next step is to grant base bandwidth. Every (allowed) link is granted `base_bandwidth = 100kB`:
 
-![State of links after granting base bandwidth](assets/nep-584/scheduler_example_2.png)
+![State of links after granting base bandwidth](assets/nep-0584/scheduler_example_2.png)
 
 This grant is subtracted from the link's allowance, we assume that all of the granted base bandwidth
 will be used for sending receipts. So the allowances change to:
@@ -727,14 +727,14 @@ increased from `100kB` to `3950kB`. Allowance on `(0->1)` is reduced by `3850kB`
 | 0->1 | 550kB     |
 | ...  | ...       |
 
-![State of links after granting 3950kB on link from 0 to 1](assets/nep-584/scheduler_example_3.png)
+![State of links after granting 3950kB on link from 0 to 1](assets/nep-0584/scheduler_example_3.png)
 
 Then' let's process `(1->1 [210kB, 430kB, 650kB])`. Can we increase the grant on `(1->1)` to 210kB?
 Yes, let's do that. The bandwidth is granted and the allowance for `(1->1)` decreased. The `210kB`
 option is removed from the request and the request is reinserted into the priority queue with the
 lower allowance.
 
-![State of links after granting 210kB on link from 1 to 1](assets/nep-584/scheduler_example_4.png)
+![State of links after granting 210kB on link from 1 to 1](assets/nep-0584/scheduler_example_4.png)
 
 | Link | Allowance |
 | ---- | --------- |
@@ -745,7 +745,7 @@ lower allowance.
 
 Now let's process `(1->2 [2.08MB])`. The bandwidth can be granted without any issues.
 
-![State of links after granting 2.08MB on link from 1 to 2](assets/nep-584/scheduler_example_5.png)
+![State of links after granting 2.08MB on link from 1 to 2](assets/nep-0584/scheduler_example_5.png)
 
 | Link | Allowance |
 | ---- | --------- |
@@ -757,7 +757,7 @@ Now let's process `(1->2 [2.08MB])`. The bandwidth can be granted without any is
 Then `(1->1 [430kB, 650kB])` is taken back out of the priority queue. Is it ok to increase the grant
 on `(1->1)` to 430kB? Yes, do it. Then the `430kB` option is removed from the request, and the request is requeued.
 
-![State of links after granting 430kB on link from 1 to 1](assets/nep-584/scheduler_example_6.png)
+![State of links after granting 430kB on link from 1 to 1](assets/nep-0584/scheduler_example_6.png)
 
 | Link | Allowance |
 | ---- | --------- |
@@ -912,8 +912,8 @@ fn calculate_is_link_allowed(
 
 It's forbidden to send receipts on a link if the last chunk on the receiver shard is missing.
 
-![Diagram showing how scheduler behaves with one missing chunk](assets/nep-584/one-missing-chunk.png)
-![Diagram showing how scheduler behaves with two missing chunks](assets/nep-584/two-missing-chunks.png)
+![Diagram showing how scheduler behaves with one missing chunk](assets/nep-0584/one-missing-chunk.png)
+![Diagram showing how scheduler behaves with two missing chunks](assets/nep-0584/two-missing-chunks.png)
 
 Sadly this condition isn't enough to ensure that a chunk never receives more than
 `max_shard_bandwidth` of receipts. This is because receipts sent from a chunk aren't included as
@@ -924,7 +924,7 @@ send some receipts, but they don't arrive immediately because chunks are missing
 shard. In the meantime other shards might send other receipts and in the end the receiver can
 receive receipts sent at multiple shards, which could add up to more than `max_shard_bandwidth`.
 
-![Diagram showing that a chunk might receive more than max_shard_bandwidth](assets/nep-584/missing-chunk-problem.png)
+![Diagram showing that a chunk might receive more than max_shard_bandwidth](assets/nep-0584/missing-chunk-problem.png)
 
 This is still an improvement over the previous solution which allowed to send receipts to shards
 with missing chunks for up to `max_congestion_missed_chunks = 5` chunks. In the worst-worst case
@@ -1018,7 +1018,7 @@ Let's say there are three shards, each shard could send and receive a bit more d
 | 2     | 1.5MB          | 4.5MB            |
 
 Shard 2 is fully congested, which means that only the allowed shard (shard 1) can send receipts to it.
-![State of links before distributing remaining bandwidth](assets/nep-584/distribute_remaining_example_1.png)
+![State of links before distributing remaining bandwidth](assets/nep-0584/distribute_remaining_example_1.png)
 
 First let's calculate how many active links there are to each shard.
 Active links are links that are not forbidden:
@@ -1056,35 +1056,35 @@ bandwidth and for every sender process the receiver in the same order:
 
 Link (0 -> 1): Sender proposes 300kB/2 = 150kB. Receiver proposes 100kB/3 = 33kB. Grant 33kB
 
-![State of links after granting 33kB on link from 0 to 1](assets/nep-584/distribute_remaining_example_2.png)
+![State of links after granting 33kB on link from 0 to 1](assets/nep-0584/distribute_remaining_example_2.png)
 
 Link (0 -> 0): Sender proposes 267kB/1 = 267kB. Receiver proposes 700kB/3 = 233kB. Grant 233kB
 
-![State of links after granting 233kB on link from 0 to 0](assets/nep-584/distribute_remaining_example_3.png)
+![State of links after granting 233kB on link from 0 to 0](assets/nep-0584/distribute_remaining_example_3.png)
 
 Link (0 -> 2): This link is not allowed. Nothing is granted.
 
 Link (2 -> 1): Sender proposes 1.5MB/2 = 750kB. Receiver proposes 66kB/2 = 33kB. Grant 33kB
 
-![State of links after granting 33kB on link from 2 to 1](assets/nep-584/distribute_remaining_example_4.png)
+![State of links after granting 33kB on link from 2 to 1](assets/nep-0584/distribute_remaining_example_4.png)
 
 Link (2 -> 0): Sender proposes 1467kB/1 = 1467kB. Receiver proposes 467kB/2 = 233kB. Grant 233kB
 
-![State of links after granting 233kB on link from 2 to 0](assets/nep-584/distribute_remaining_example_5.png)
+![State of links after granting 233kB on link from 2 to 0](assets/nep-0584/distribute_remaining_example_5.png)
 
 Link (2 -> 2): This link is not allowed. Nothing is granted.
 
 Link (1 -> 1): Sender proposes 4.5MB/3 = 1.5MB. Receiver proposes 33kB/1. Grant 33kB
 
-![State of links after granting 33kB on link from 1 to 1](assets/nep-584/distribute_remaining_example_6.png)
+![State of links after granting 33kB on link from 1 to 1](assets/nep-0584/distribute_remaining_example_6.png)
 
 Link (1 -> 0): Sender proposes 4467kB/2 = 2233kB. Receiver proposes 233kB/1 = 233kB. Grant 233kB
 
-![State of links after granting 233kB on link from 1 to 0](assets/nep-584/distribute_remaining_example_7.png)
+![State of links after granting 233kB on link from 1 to 0](assets/nep-0584/distribute_remaining_example_7.png)
 
 Link (1 -> 2): Sender proposes 4234kB/1 = 4234kB. Receiver proposes 4.5MB. Grant 4234kB
 
-![State of links after granting 4234kB on link from 1 to 2](assets/nep-584/distribute_remaining_example_8.png)
+![State of links after granting 4234kB on link from 1 to 2](assets/nep-0584/distribute_remaining_example_8.png)
 
 And all of the bandwidth has been distributed fairly and efficiently.