---
tags: meson
---

# Parameterizing Meson
We need to be able to determine what parameters are needed in order to better inform computational requirements for being a provider, authority, mix.

## Properties
Meson has a stratified topology. We need to consider the following things when parameterizing:
* # of ingress providers
* # of egress providers
* # of mix layers
* # of mixes in each layer
* # of clients connecting to ingress providers

## Experimentation setup from the Loopix paper

- Mix nodes were on EC2 instances with 64 GBs of RAM and 2.3 GHz
- Providers were also on EC2 instances but with 256 GBs of RAM

## Response from Tariq's email:
The main measures you are likely interested in are 1) the latency (time
for messages to reach their destinations, 2) the amount of privacy leak,
and 3) the number of mixes and service providers that have to be running.

Now for the parameters: There are two main categories. The first are
those that are external, such as how many users of the system there
are/will be, how many service providers want to be part of the network,
and how many mixes they could afford. These are not for tuning, since
they are more like constraints. The second are those that are internal,
like mix delay, sending rate. These are for tuning.

Lets consider the topology of your network. To imitate real life, you
are likely to need a few more mixes than 1. As a general rule, it is
sensible to start with 6 mixes arranged in 3 layers of 2 mixes each in a
stratified topology. Split your Service Providers in front (the ingress
side) and at the end (the egress side) of this stratified network. You
can tweak these mix and layer numbers depending on your needs and threat
model, however, go no lower than 2 layers otherwise you will have to
assume that all the mixes in the only layer are honest. Also, there are
diminishing returns for security and privacy after 4 layers.

The next thing is the client sending rate and the delay parameters for
your network. Both are correlated and their relationship is inversely
proportional to each other. I would recommend to first decide on the
number of users your network will support and on average how often each
user will have transactions (or more generally, messages) to send into
the network. This is your sending rate parameter. To get these numbers
see what real world crypto networks' client message rates are like.

You can now vary the delay according to the number of layers, the
sending rate, the privacy leak, and also the service level (latency) you
want to maintain. The only thing to manage is that the sending rate and
delay should not cause the situation where not enough messages are in a
mix at any given time. For instance, a low sending date and a low delay
will mean it is likely that the mixes will be empty and a lone message
will come into and leave without being mixed with another message, hence
a large privacy leak.