# ICRP: Internet-Friendly Cryptographic Relay-Detection Protocol
## 5 Performances
### Analysis
#### 5.2.2 Throughput  
In this section, we test the impact of parameters \(n\), \(p\), and \(k\) over the sending time of large blocks of data. We then compare those times with the throughput given by the sending of raw UDP packets unsupervised by ICRP. Impact of Parameters \(n\) and \(k\)  
We see on Table 2 the times in seconds involved in an \((n,500,k)\)-sending of 20 Megabytes (resp. 100 Megabytes) of data using 3 possible values of \((n,k)\) which are \((250,160)\), \((320,125)\) and \((400,100)\) (resp. \((250,800)\), \((320,625)\) and \((400,500)\)). The parameter \(p\) remains constant to 500 bytes for those tests. For this configuration, we see that the number of sessions \(k\) and rounds \(n\) creates no visible impact on the overall sending time. \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline \(n\) & **256** & **512** & **768** & **1024** & **1280** & **1536** \\ \hline n\({}^{\circ}\) of compression & 2049 & 4098 & 6147 & 8196 & 10,245 & 12,294 \\ \hline Hashing time (ms) & 0.731 & 1.479 & 2.253 & 2.834 & 3.813 & 4.434 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: ICRP final Hash complexity (using \(SHA256\)) with \(p=512\) bytes. Impact of Packet Size \(p\)  
As it was stated in [27], the packet size has a low impact on the sending time of a single packet. This means that the more data contained within every single packet, the faster the sending of the overall message (containing multiple packets) will be. Figure 15 shows the evolution of the time to send 100 Megabytes of data depending on the size of the individual packets. We can observe that the time decreases for realistic values of \(p\). The maximum size of UDP packets is implicitly specified in the official IETF documentation RFC768 [32], as the UDP header contains a field called \"Length\". This field is 16 bits in size and represents the length in bytes of the packet (header included), which means the theoretical maximum size for a UDP packet would be 65,535 bytes. In practice, however, most services (for instance DNS) restrict the largest packet length to 512 bytes in order to respect the Maximum Transmission Unit (MTU) on the Internet and avoid frequent packet loss. Comparison with a Direct Sending of UDP Packets  
To see how ICRP performs, we compared the times involved in the sending of a given amount of data between two fixed nodes, using our prototype implementation and a direct sending including no time measurements, authentication, or acknowledgments. As Figure 15 has demonstrated, the size of individual packets has an impact on the global sending time of a file. Hence, those 2 methods should send packets of comparable sizes. The following Table 3 displays the measures of the overall sending of 10, 40, 100 and 200 Megabytes of data using the two methods with a constant packet size of 500 bytes and compares the obtained Throughput. The average throughput is about 2.15 Mb/s for direct sending and about 1.79 Mb/s using ICRP. The measures were performed between a personal computer based in Caen, France, and a Server supplied by AWS (Amazon Web Services). The slight loss in performance is due to the fact that ICRP has to handle multiple threads concurrently on both the Sender's and Receiver's side, which is obviously not the case for direct sending. It induces that the processing capabilities of the endpoints have an impact on throughput \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline \multirow{2}{*}{**Size (Mb)**} & \(n\) & \(k\) & \(n\) & \(k\) & \(n\) & \(k\) \\ \cline{2-7}  & **250** & **160** & **320** & **125** & **400** & **100** \\ \hline
20 & & 3.65 & & 3.56 & & 3.53 \\ \hline \multirow{2}{*}{**Size (Mb)**} & \(n\) & \(k\) & \(n\) & \(k\) & \(n\) & \(k\) \\ \cline{2-7}  & **250** & **800** & **320** & **625** & **400** & **500** \\ \hline
100 & & 16.71 & & 16.81 & & 16.62 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: ICRP sending times in seconds for 20 Mb and 100 Mb depending on \(n\) (number of rounds) and \(k\) (number of sessions).