diff --git a/docs/learn/protocols/iota2.0/core-concepts/communication-layer.md b/docs/learn/protocols/iota2.0/core-concepts/communication-layer.md
index b2394b0a4d8..487ca917466 100644
--- a/docs/learn/protocols/iota2.0/core-concepts/communication-layer.md
+++ b/docs/learn/protocols/iota2.0/core-concepts/communication-layer.md
@@ -62,10 +62,10 @@ RMC is computed according to an algorithm based on recent traffic activity, wher
 Let the number of blocks issued by accounts not in debt at slot $i-$MCA be $n_{i-MCA}$. Hence, if $n_{i-MCA}$ is lower than a given threshold $T_{low}$, then RMC decreases; otherwise, if $n_{i-MCA}$ is larger than a threshold $T_{high}$, then RMC increases. The value RMC at slot $i$ is calculated as:
 
 $$
-RMC*i = \begin{cases}
-\min(RMC*{i-1} + \alpha; RMC*{max}) &\text{if $n*{i-MCA}>T*{high}$}\\
-\max(RMC*{i-1} - \beta; RMC*{min}) &\text{if $n*{i-MCA}<T*{low}$}\\
-RMC*{i-1} &\text{otherwise}
+RMC_i = \begin{cases}
+\min(RMC_{i-1} + \alpha; RMC_{max}) &\text{if $n_{i-MCA}>T_{high}$}\\
+\max(RMC_{i-1} - \beta; RMC_{min}) &\text{if $n_{i-MCA}<T_{low}$}\\
+RMC_{i-1} &\text{otherwise}
 \end{cases}
 $$
 
@@ -114,21 +114,19 @@ Once the block has successfully passed the filter checks and is solid, it is enq
 
 The outbox is logically split into several issuer queues, each one corresponding to a different block issuer account. Blocks within each issuer queue are sorted by their timestamp in increasing order, with the oldest block at the head of the queue. We have empirically proven that sorting blocks by timestamp guarantees consistency across nodes even during highly congested periods. Furthermore, each queue is assigned a priority counter value, called *deficit*, which is used to guarantee throughput to issuers and protect the available bandwidth from malicious actors.
 
-The DRR scheduler iterates over all issuer queues in sequence and increments its deficit according to a *quantum*, which is a value proportional to the account's Mana and BIC (note that we only consider the Mana in the account's output; any other address associated to the account will not alter the quantum). The deficit value represents the maximum amount of bytes that can be sent per issuer at a given turn: if the deficit counter is greater than the work score of the block at the head of the queue, this block will be scheduled and the value of the counter is decremented by the block's work score. ICCA schedules blocks at a maximum scheduling rate $\mu$: this rate is computed in work -- see above -- per second implying that the time between the scheduling of two consecutive blocks is equal to the work score of the first scheduled block times $\mu$. To keep the network latency bounded, we add a cap $maxDeficit$ on the maximum deficit that an account can accumulate. Furthermore, blocks can only be scheduled when they are ready, meaning that all parents are either scheduled or accepted.
+The DRR scheduler iterates over all issuer queues in sequence and increments its deficit according to a *quantum*, which is a value proportional to the account's Mana and BIC (note that we only consider the Mana in the account's output; any other address associated to the account will not alter the quantum). The deficit value represents the maximum amount of bytes that can be sent per issuer at a given turn: if the deficit counter is greater than the work score of the block at the head of the queue, this block will be scheduled and the value of the counter is decremented by the block's work score. ICCA schedules blocks at a maximum scheduling rate $\mu$: this rate is computed in work -- see above -- per second implying that the time between the scheduling of two consecutive blocks is equal to the work score of the first scheduled block times $\mu$. To keep the network latency bounded, we add a cap $maxDeficit$ on the maximum deficit that an account can accumulate. Furthermore, blocks can only be scheduled when they are ready, meaning that all parents are either scheduled or accepted. Below is an approximate piece of pseudocode illustrating how the DRR scheduler operates.
 
 ```vbnet
-IF Len(outbox) > 0
-    b = outbox[ID].head
-    WHILE ID.deficit < b.work_score OR b.timestamp > now() OR (parents(b) not scheduled OR not accepted)
-        ID.deficit += mana[ID]
-        IF ID.deficit > maxDeficit
-            ID.deficit = maxDeficit
-        ID++
-    ID.deficit -= b.work_score
-    IF ID.deficit < 0
-        ID.deficit = 0
-    schedule(b)
-pause(mu*b.work_score)
+FOR ID in round robin over all accounts
+    ID.deficit += ID.quantum
+    IF ID.deficit > maxDeficit
+        ID.deficit = maxDeficit
+    IF Len(outbox[ID]) > 0
+        b = outbox[ID].head
+        IF ID.deficit >= b.workScore AND (parents(b) scheduled OR accepted)
+            ID.deficit -= b.workScore
+            schedule(b)
+            pause(mu*b.workScore)
 ```
 
 In order to provide a high-performance system, each validator issues a fixed number of special blocks per slot, called *validation blocks*, which receive special treatment during scheduling and do not burn any Mana. A second scheduling buffer, reserved for validation blocks only, includes a set of queues, one for each validator, in which blocks are scheduled in the order they are received. If a validator issues more validation blocks than its allowance, the validator will not receive rewards for the given epoch, and its Mana balance will be decreased by an amount proportional to its stake.