collecting all relevant model and simulation parameters in one place

[rkuhn]

As @bwbush suggested, I have started creating a document that lists all parameters for models and simulations of Ouroboros Leios: https://github.com/input-output-hk/ouroboros-leios/blob/main/docs/simulation-model-parameters.md

It would be very useful to collect the parameters used in the Haskell and Rust simulations as well as the ΔQ model so that we all work on the same foundation. Unfortunately, my knowledge is not yet extremely deep and wide, so I can just start and hope for others to chime in and contribute (@Quantumplation @Saizan @wenkokke @SupernaviX @yveshauser @will-break-it @dcoutts ). Let’s use this discussion to coordinate.

Please take a look at the doc to check if you agree with the level of detail illustrated on the Block Producer as an example. I’ll transfer the network latencies used so far from the Peras TechReport 1, probably tomorrow.

[SupernaviX]

This action is a two-step process where the recipient asks for the block by sending a request to the sender, who will then transfer either the block or an error response back to the recipient. Note the inversion of control here, which is deliberate to implement strict flow control on the network: a node manages its own ingress traffic by asking for blocks to be sent to it.

I haven't implemented ranking blocks yet, but for Praos blocks I've been simulating it as a three-step process:

1. node A tells node B it has a new block (basically a MsgRollForward from the chain-sync protocol)
2. node B asks node A for the new block (like requesting a block in the block-fetch protocol)
3. node A sends node B the new block (like sending a block in the block-fetch protocol)

My model is overly simplified, it doesn't account for batching or anything. But I think the first part is necessary to model block propagation.

[rkuhn]

Indeed, I’m fixing the description to include the announcement step (that is usually conveniently ignored because it is supposedly “almost free” but certainly adds latency).

[Saizan]

Should we start by sharing in this discussion the currently used parameters by each simulation?

On our side we are just about getting started with Leios, but what we have for the praos/ranking block simulations are:

• Protocol parameters:
  • ranking block validation delay
  • ranking block header validation delay
  • ranking block body size (fixed to 96 KB atm)
  • ranking block header size (fixed to 1 KB atm)
  • expected slots between ranking blocks (feeds into a poisson distribution)
• Network parameters:
  • Directed graph of nodes, with ranking blocks going from target to source (of each edge).
  • latency and bandwidth, for each link between nodes.
  • stake per node (fixed to uniformly distributed atm)

Since we are all simulating the communication protocols at different layers of abstraction it seems inappropriate to me to make
message sizes, e.g. for a block body request, into shared parameters. What we can do though is provide aggregate measurements that can help tune inputs for more abstract simulations?

Another thing to note is that I expect RB body size to later become a function of certificate size, etc., though we should still have a maximum.

[rkuhn]

Thanks for the details, I added the number of block_producers to the list of parameters so that the stake can be computed from it.

Regarding the message sizes: as far as I can see all simulations model the sending of individual messages, albeit with different level of detail, so it would indeed make sense to me to have these sizes as shared parameters. Tracking average and maximum might make sense, but I’d need to understand what exactly we want to do with the differentiation before I can propose a model.

Regarding ranking blocks: it was my understanding that header/body separation was a new thing in Leios, and thus absent in Praos, which is what the ranking blocks are, right? In other words, I thought that header/body separation applies only to IBs and EBs. Please let me know if this is incorrect.

While we’re on this topic, I added separate parameters for the allocated bandwidths for transaction diffusion, Praos, and Leios, respectively. Is that the correct approach?

[Saizan]

Re ranking blocks: I believe the header/body doesn't exist in the high level spec of praos, but it does exist in the current implementation. In short, headers are used by nodes in the ChainSync mini-protocol to learn about the preferred chain of their peers and decide what chain to "target" next, otoh a node uses the BlockFetch mini-protocol to request whatever block bodies it needs. More details in the "Mini protocols" chapter of the ouroboros-network spec.

Re message sizes: while we are all modeling individual messages, our "protocols" might differ quite a bit, in the Haskell simulation we do model the two mini-protocols mentioned above. In that setup it seems quite unclear how to obey an annoucement_size parameter for ranking blocks, for example.

Re bandwidth allocation: we could model separate bandwidths (each with their own tcp window, most easily), I am not positive it's what you'd want to go for in practice. I don't believe the current node impl. allocates specific bandwidth for transactions, for example? (cc @dcoutts ).