5.4 Token-based Accounting Simulation
5.4.2 Experiments
Simulated is the file sharing scenario described above. 5.4 summarises the simulation parameters. The core interests of the simulation is the influence of the quorum size t, the account holder set size k, and of churn on the traffic created by the token based accounting scheme.
In order to analyse the influence if these parameters on the created traffic, the measurements for four different parameter values will be analysed. Using four measuring points, it can be analysed whether the created traffic develops in a linear way or in different way. In order to analyse the effects of one
GUID +sendMessage() +peerUnavailableUpdateChord() «utility» TokenAccountingUtils +getSuccessorPeer () : GUID +getPredecessorPeer() : GUID +lookupPeer() : GUID +findNextTrustedPeer() : GUID +getRandomTrustedPeer() : GUID «implementation class» ChordFinding Strategies
Connection Classes to Overlay
Overlay Layer «system» chord Network Layer Simulation Layer «system» simulator «system» subnet «uses» «uses» +notifyOnline() +performAction() +scheduleLogoff() +scheduleOffline() +scheduleOnline() +scheduleNextTransaction() +isAvailableFotActions () : bool +isAvailableForTransactions() : bool +performTransaction() +isAvailableForActions () : bool +swapTokens() «signal»-serviceRequestReceived () «signal»-requestAcceptanceReceived () «signal»-providerDecisionReceived () «implementation class» TokenUserRole -leaveTime : long -cleanLogout : bool -online : bool User Layer Application Layer «uses» «uses»
parameter on the token-based accounting scheme, a base scenario is defined and the experiments will vary only one parameter at a time (ceteris paribus).
Now the base scenario is described.
5.4.2.1 Experiment Parameter Overview
Basic Settings
• Duration: The selected scenario will be simulated for the time of one day (24 hours).
• System Size (N ): The system size N is 1000 peers. A larger system size led to a simulation that exceeded the selected duration.
• Used Overlay: For the peer-to-peer system the Chord implementation in PeerfactSim.KOM was applied.
• Peer Bandwidth (c): All peers have the same bandwidth available. A typical DSL-link with 128 kBit upstream (ci
up= cup= 128 kbit)and 1024 kBit downstream (cidl= cdl= 1024 kbit)was selected. • Key Length (r): The key length of the peers’ key and the system key pair. Since the hypothetical
TWIRL machine can factorise RSA-keys within one year (ST03), today a length of 2048 bit is suggested. Although the BLS-threshold scheme uses shorter signatures, as a worst case decision in the simulation r was set to 2048 in order to reflect the traffic that the use of the URSA-scheme would introduce.
• Trusted Peer Ratio (ptp): The trusted peer ratio was set to ptp = 33.33%. The selected churn (see below) means that approximately 30% of all peers are concurrently online. In order to enable a varying quorum for the largest quorum size t = 17, a total number of T = 100 trusted peers seemed a reasonable base value. Accordingly, ptpwas selected.
• Trusted Peers’ Trustworthiness (pg): It is assumed that the ratio of good peers among the trusted peers is at least pg = 50%. This value is required in order to calculate the required quorum size. • Account Holder Set Maintenance (fck, fcp): The account holder set methods depend on the fre-
quency the account holder set size is checked fckand the frequency the account position is checked fcp. For the simulation fck is set to 300 seconds and fcpis set to 600 seconds, likewise for the sim- ulation for determining the optimal account holder set size.
Quorum Size
For the quorum size, different performance values of the token-based accounting scheme are applied. The scheme is evaluated with Trust Levels L = 99%, 99, 9%, 99,99% and 99,999%. This results for the selected pg = 50%in quorum sizes t = 7, 10, 14, and 17.
Account Holder Set Size
Because the preferred account holder set size k’s influence of different account holder set sizes on the created traffic, the account holder set size will be varied k = 6, 8, 10, and 12, as these are the results from the simulation of the account holder set maintenance mechanisms (see above).
Churn
Churn is modelled using the results from (SENB07b).
• Online Time (don): The base peer lifetime is a Weibull distribution with α = 0, 61511 and β = 169, 5385, measured in minutes. For the simulation, we assumed that peers are online at least
don, min = 30 seconds. This assumption helped to keep the Chord ring more stable. Also, as DSL-connections are typically reset after 24 hours, the maximum possible online time was set to don, max= 24hours. The maximum simulation time was 24 hours. A longer online time could not be reflected in the simulations.
• Offline Time (dof f): The base peer offline distribution is a Weibull distribution with α = 0, 47648 and β = 413, 6765, also measured in minutes. The same minimum dof f, min = 30 seconds and maximum dof f, max= 24hours have been applied to the offline time distribution.
In order to analyse churn, both distributions are multiplied with factors dvar of 1.0, 0.5, 0.33, 0.25. At the beginning of the simulation ,all peers are offline. In order to bring the peers into the system, each peer will join after half of an offline time period. That simulates that the system was pre-existing.
• Log Off Behaviour (plog−of f): The basic probability for a log off (in contrast to a leave) was set to plog−of f = 90%. As users typically close the application when they leave the system, the remaining 10% are thought to reflect crashes, connection failures, etc.
Application Parameters
Note that the application parameters are required to create traffic for the token-based accounting scheme. It is not used to evaluate the efficiency of a file sharing application. This is beyond the scope of this dissertation.
Moreover, there are no measurements of the transaction frequency and file size distributions for the scenarios where the churn was measured. As it is more important for the simulation of the account holder set to use a realistic churn model in the simulation, it was decided to apply a realistic churn model, and create distributions for transaction frequency that model meaningful user behaviour in a scenario where the token-based accounting scheme is applied.
• Transaction Frequency (ft): A peer will request services according to a normal distribution ftwith a mean µ = 1800 seconds (30 min) and a standard deviation σ = 1800. The distributions minimum was set to 60 seconds and maximum to 7200 seconds (2 hours).
• File Size and Transaction Value (s): The distribution of file sizes is thought to model an mp3-file sharing scenario. Accordingly, a normal distribution was applied with µ = 6 and σ = 6. Also for this distribution a minimum of smin = 1and a maximum of smax = 13was set in order to reflect typical file sizes for such an application type in MBytes.
• Dead Period Before Leave (ddead): When closing an application, the time that is required to finish all open tasks. This period was set to 20 seconds.
• Aggregation Function M = A(F n1, ..., F nn): In the file sharing application a peer receives as many new tokens as old tokens were aggregated. M = n, where n is the number of foreign tokens sent for aggregation.
Token-Accounting User Behaviour
• Swap Threshold (b): User exchanged all their foreign tokens when they collected more then 25 foreign tokens.
• Lower Swap Threshold (bmin): When a user is in need for tokens in order to do further transactions, it collects at least 3 foreign tokens before swapping them. This is also the minimum value of a transaction.
Table 5.4: Simulation Scenario Parameters
Parameter Description Values
N Total number of peers in the system. All peers in the
system are normal peers. 1000
ci
up Upload link capacity of peer i 128 kBit
ci
dl Download link capacity of peer i 1024 kBit
r Length of used keys 2048 bit
ptp Target ratio of trusted peers to normal peer in the system 33,33% T Total number of trusted peers in the system; results from
ptp.
≈ 300
t Quorum size 17, 14, 10, 7
L Trust Level, depending onT, t, pg
99%, 99.9%, 99.99%, 99.999%
k Preferred Account Holder Set Size 6, 8, 10, 12
x Account Shift Value 5
fck Frequency account holder set size check 300 sec
fcp Frequency account holder set position check 600 sec
ft Frequency a user requests a service NormDist(1800; 1800),
min = 60 sec, max = 7200 sec
s File size distribution resp. service value distribution NormDist(6; 6), min = 3, max = 13
b Swap threshold 25
bmin Lower swap threshold 3
bstart Number of starting tokens 50
A(F n1, ..., F nn) Aggregation function A = n
don Peers’ lifetime distribution Weibull(0,61511;
169,5385);
min = 30 sec, max = 86400 sec
dof f Peers’ offline time distribution Weibull(0,47648;
413,6765);
min = 30 sec, max = 86400 sec
dvar Churn modification factor 1
plog−of f Probability for logoff 90%
ddead Dead period before a peer leaves 20 sec
V System-wide traffic volume
Table 5.5: Simulation Message Size Parameters
Parameter Parameter Size [Byte]
MTU lM T U 1500 Overlay Address lID 20 I²P Header lIP 10 Transport Header lT CP 10 Key length r 256 Delimiter ldel 2
Response Identifier lresp 4
int value lint 4
long value llong 8
double value ldouble 8
Token Parameter Size [Byte]
Fresh unsigned U 282
Partially Signed P 540
New Own Token T 540
Used Foreign Token F 1096
5.4.2.2 Message Sizes
Calculating Message Sizes
Each message sent in the token-based accounting simulation has a specific size. The size is composed of the basic required headers of the IP- protocol and the TCP or UDP-protocol, as well as the information the message carries. Each information field is delimited by a delimiter. All message types can carry different amount of information. Depending on the information carried, a message’s size is calculated in the simulation. Table 5.5 describes the assumed sizes of different types of information.
The message sizes are considered fixed parameters in the simulation and result from either the applied overlay network or the messages used in the token-based accounting scheme. They will not be varied in the simulation.
The MTU is used in order to calculate the number of fragments a message is split into, and with this to calculate the actual traffic sending a specific message creates because per fragment IP- and TCP/UDP headers are required to be added.
Token Sizes
There are four different kind of tokens used inside the token-based accounting scheme. When tokens are created in the first place they contain the information required to identify it. These fresh unsigned tokens are composed of a date (type: long), a serial number (type: int), an owner ID (type: key), an account ID (type: int), and the required five delimiters. This results in 282 Bytes. Partially signed tokens also contain a signature (type: key), as well as a further delimiter. This results in 540 Bytes. New own tokens have the same size. Used tokens additionally contain transaction ID (type: int), transaction time (type: long), transaction object (type: overlay ID), provider ID (type: key), owner signature (type: key), and six delimiters. This results in a size of 1096 Bytes. Furthermore accounting information added to used tokens was not considered in the simulation.
5.4.2.3 Experiment Overview
This section gives an overview on the performed experiments and the base experiment the other experi- ments are derived from.
Performed Experiments
The basic experiment uses the values given in Table 5.4 for the parameters of the token-based ac- counting scheme. All experiments use as traffic parameters the values given in Table 5.5. Three main influencing factors on traffic generated by the token-based accounting scheme will be analysed: The
Table 5.6: Experiments Overview t k dvar Base 17 10 1 Quorum 14 10 7 AHSS 12 8 6 Churn 1 2 1 3 1 4
influence of the quorum size t, the influence of the account holder set size k, and the influence of churn by varying the churn modifier dvar. For each factor, four different scenarios were simulated; this allows for further understanding of how traffic develops; i.e., is the traffic growth linear, exponential, etc.
In order to analyse the influence of the main parameter of the token-based accounting scheme on the created traffic, one parameter at a time is varied and all other parameters are kept constant (ceteris paribus).
The influence of the quorum size t on the traffic created is analysed by using different Trust Levels L(T, t, pg) = {99%, 99.9%, 99.99%, 99.999%}. It is assumed that at least pg = 50%of the trusted peers act honestly. For the system size of N = 1000 peers and a trusted peer ratio ptp> 10%, the required quorum sizes result in t = {7, 10, 14, 17}.
The account holder set size k depends on the churn in the system. Accordingly, the account holder set would be increased with stronger churn. However, in order to be able to analyse the influence of the account holder set size k on the traffic generated, churn has to be kept constant. Otherwise it would interfere with the results. The simulated values are deduced from the simulations of the account holder sets, presented in Section 5.2.2. Set sizes of k = {6, 8, 10, 12} will be simulated in order to cover a broad range of churn scenarios.
In order to analyse the influence of different churn, a basic churn model is used and this is modified by the churn factor dvar. In the basic churn model the results from (SENB07b) are applied, which have also been applied for the account holder set size simulations (see Section 5.2.2). Both, peer lifetime and peer offline time, are distributed according to Weibull distributions with parameters listed in Table 5.1. Likewise, the analysis of the account holder set size, both distributions are modified with the churn factor 0 < dvar ≤ 1, which increases the influence of churn, as peer lifetime and peer offline time are reduced. dvar is chosen as dvar =1,12,13,14 .
Furthermore, in order to study the scalability of the token-based accounting scheme, i.e. the effect of different system sizes, the system sizes of N = {1000, 250} are used.
Base Experiment
The base experiment uses the highest trust value L(T, t, pg) = 99.999%, which results in a quorum size of t = 17. The base account holder set size is set to k = 10, in order to allow conduct the churn experiments ceteris paribus. As base churn the churn factor is set to dvar = 1.
Table 5.6 summarises the performed experiments. Number of Repetitions per Experiment
In order to determine the required number of repetitions per experiment, the central limit theorem (BGG94) is applied. Each experiment runs with either 1000 or 250 peers. Thus, according to the the
central limit theorem, it can be assumed that the average traffic created per time period is normally distributed. For computing meaningful confidence intervals, the sample size should be at least ten. Therefore, each experiment is repeated 12 times.
As the traffic is normally distributed for computing the confidence intervals, the student t-distribution has to be applied for the given experiment size (cf. (BGG94)).