Colin, thank you for the questions. In the original token simulator we had an estimated number of network units generated by the amount of CU and SU generated by the machine. In the screenshot you can see these highlighted in the top red box. The bottom red box has the unit price (set by farmers but TF Network will have a default price). In fiat the income generated by this (assumed) network traffic is between $36.40 for the smallest box and $1385.34 for the large one per month. This revenue was accounted for in the overall ROI calculation. It represents between 5.9% and 6.7% of the total overall income making up the ROI. We can take similar assumptions and add to the revenue stream in the new farming simulator.
The assumptions are based on best practise, if you have x amount of CPU and y amount of storage then an average amount of “network” is needed to work this capacity. I am happy to help and try to get to a better and more understood set of assumptions but the actual billing of this is going to work based on actual traffic in / out of TF Grid nodes.
The principle embedded in the billing mechanism accounts for traffic in and out (Received and Transmitted) for each node on which a consumer has CU and SU reserved. The only way to use zero-OS primitives (container, volume, 0-DB namespace, private network, kubernetes VM) is to connect to them over the network (the peer2peer encrypted wireguard network). Hence all reservations done will create network traffic.
Any architecture created, single node or multi node, will result in network usage and this will all be accounting towards the user (3bot wallet of) that makes this reservation.
