# Quantum Key Distribution in Kubernetes Clusters
## 6 Test and Validation
### Key Exchange Time and Throughput  
We started the tests with some assumptions regarding the exchange rate at the QKDM/QKD device levels. For these tests, we used a special-purpose QKDM which allows exchanging the key at a specific rate between QKD nodes. This is useful because we could change this rate and analyse the system's behaviour in different conditions. These tests, focusing on the QSS at QKS and QSS operator level, are entirely agnostic to the underlying devices. Eventually, as future work, they could be enhanced using a QKD simulator as in [3]. Since we could set the low-level exchange rate between devices arbitrarily (to values far beyond the capability of the systems--up to 2 Mbit/s) we started attesting the key exchange capacity of the QKDMs. We immediately noticed that the bottleneck of this process is the Vault. Indeed, given the Vault key size configuration at a value of 128 bits and the fact that to store a key we need on average 5.6 ms, we could exchange a maximum number of 178 keys/s from a QKDM to another one, that is a throughput of 22.8 kbit/s. Even if this value is compliant with the current QKD devices, clearly it has to be enhanced in order to support future and more advanced systems. To enhance the performance, we could act on two aspects: replicating the Vault instance, since it is running in a pod, or expanding the size of the keys. The first approach has certain limits since Vault is a resource-demanding application. The second approach is feasible and straightforward and could be simply be adopted by changing some parameters in our solution. We decided to adopt this key size because we wanted to avoid wasting key material, so we chose the minimum reasonable amount of bits to represent one key and compose longer keys. Summarising, the primary assumption for all the following tests is that the maximum low-level throughput is of 22.8 kbit/s and keys exchanged among QKDMs have a length of 128 bits. In our first test (Figure 8), we collected data regarding the execution time related to the application of a KeyRequest type resource. This takes into account the time for the QKS to perform the getKey operation, which is the greediest in terms of time requested, and all other operations performed by the QSS operator that are labelled as \"QSS operator time\" (Figure 7). Varying the number of keys requested and the length of those keys, we observe an expected growth in terms of time required for the QKS to perform the getKey, while the time of the operator remains constant. Even if all the required keys are already available in Vault, we need to consider that the getKey operation has to perform the KRP according to the number of keys requested and then extract those keys from Vault, whose time depends on both the number and length of the required keys. We covered the part of the optimisation regarding the length of keys in Vault, yet there is the necessity to tackle the multiple requests factor. In order to optimise that aspect, we already adopted the asynchronous approach (Section 3.1); indeed, the performance of the system, even considering the QKDM bottleneck, the fact that we used only one worker in Hypercorn for the tests, and only one replica of the QKS in Kubernetes, are already satisfying, i.e., for 100 keys of length 1024 the throughput is approximately 56 kbit/s. Since our system is modular and scalable, we could adjust the parameters above (e.g., Hypercorn workers, QKS replicas) according to the coming evolution of QKD devices and reach throughput far beyond the one reported in this paper. The second test, as depicted in Figure 9, shows the success rate of the KeyRequest depending on the underlying exchange rate. In order to perform the tests, we set first the throughput of the special purpose QKDM to 2 kbit/s, then to 1 kbit/s and varying the rate of the requests we tested the resilience of our solution. As we expected, we see in Figure 9 that using a 2 kbit/s low-level exchange and requesting 1 kbit/s of key material leads to 100% success in key exchanges.