Instal·lació de protecció contra incendis

Most important for the evaluation of the token-based accounting scheme is the traffic the scheme intro- duces into the system. Before the traffic will be simulated, a worst case assessment will be performed. There are three parts in the token-based accounting scheme that can be assessed separately. The first part is traffic created by transactions between peers, i.e., when a peer requests and receives a service from another peer, and the token aggregation processes conducted due to these transactions. The second part is the traffic created from managing account holder sets. The third part is the key management traffic created when the key shares owned by the trusted peers are updated.

For the analytical assessment, the number of messages required will be calculated. Message sizes will be regarded in the scheme’s simulation.

5.3.1 Analytic Transaction Traffic Assessment

In the token-based accounting scheme, traffic created due to transactions and token aggregation pro- cesses is relatively deterministic since the majority of messages created is independent of current system size and of churn. However, the number of hops a lookup message travels in the overlay depends on system size and churn rate.

Considering the token-based accounting messages (and not considering the overlay messages) the important parameters are:

• Number of Transactions n • Quorum Size t

• Account Holder Set Size k

• Average Transaction Value s: The average number of tokens spent by a peer in one transaction. • Batch Size b: The average number of tokens swapped in a token aggregation process

Transaction

Messages required to request a service will not be considered in the analytical assessment, as these messages belong to the application and not directly to the token-based accounting scheme.

The traffic for one transaction using the trustworthy transaction protocol is composed of the following number of messages:

• Requester sends unsigned tokens to provider: 1

• Provider checks these tokens with the account holder set: 1 + 2k Now the provider starts the service provisioning.

• During the service provisioning, the requester sends token by token to the provider: s • Optionally, the reception of a token could be approved by the provider: s

Accordingly, for one transaction the number of messages created results in: MT rans(k) = 2 + 2k + 2s. Token Aggregation

For assessing the traffic of one token aggregation process, it is assumed that the peer swapping tokens provided each service to a different peer. Accordingly, there must be b

s aggregation accounts checked for double spending. Like for transactions, the overlay lookup operations are not considered in this analysis. A token aggregation process requires the following number of messages:

• Swapping peer sends b foreign tokens to random trusted peer: 1

• The trusted peer queries the account holder set in order to determine the administrating trusted peer: 1 + 2k

• The trusted peer forwards the foreign tokens to the aggregation administrator: 1

• In order to detect double spending, the aggregation administrator queries all aggregation accounts of the owners of the foreign tokens: b

s(1 + 2k)

• The administrator forwards the fresh tokens to the quorum: t

• The quorum peers update the swapping peer’s aggregation account: t(1 + 2k) • The quorum sends the partially signed tokens to the swapping peer: t

For one aggregation process, the number of messages created results in: MAggr(k, t, b) = 2 + (1 + t + b

s)(1 + 2k) + 2t

Complete Transaction Dependent Traffic

The traffic created due to transactions and aggregation processes is not dependent on time but solely on the number of transactions performed by the system’s peers. An aggregation process will be performed on average every ns

b transactions. Accordingly, the number of messages can be assessed using Equation 5.2, where n is the number of transactions performed.

M (n, k, t, b) = n(2 + 2k + 2s) + ns b (3 + b s + 3t + 2tk + 2k( b s+ 1)) (5.2)

5.3.2 Analytic Account Holder Set Management Traffic Assessment

Unlike the transaction related traffic, the account holder set management traffic depends on churn of peers and on time, because accounts are handed over when peers leave and there are frequent actions controlling and repairing account holder sets.

As described above, churn in p2p systems can not be described using exponential functions. Therefore, Markov Chains and queueing theory cannot be applied to model the traffic created from churn. This part of traffic will only be regarded in the simulation.

Account holder set management consists of two mechanisms.

• Detection of replica number and adding account holders if necessary. • Detection of correct account holder set position and moving it, if necessary.

Apart from the account holder set size (k) there are two frequencies to be determined as system param- eters.

• fckis the frequency an aggregation account’s set size is checked. • fcpis the frequency an aggregation account’s position is checked.

5.3.2.1 Simple Mechanism Analysis

For managing the account holding sets the following mechanisms are used: Detection of replica number, detection of correct account position, account holder set locking, account consistency, account move- ment, and graceful account handover. The message created by the mechanisms is summarised now. The number of messages stated here is only correct if the overlay’s structure is completely correct, and no involved peers fail or go offline during runtime of such a mechanism. Lookup operations are not considered.

Detection of Replica Number

• One account holder to the first account holder administering the detection: 1 • The administering account holder to all other account holders: k − 1

• The other account holders to the administering account holder: k − 1 The sum of messages created results in: MRN(k) = 2k − 1

Adding a New Account Holder

• Administering account holder to last account holder: 1 • Last account holder to new account holder: 1

• Response of new holder to administering holder: 1 • Transfer of account data: 1

• Confirm transfer: 1

Detection of Correct Account Position

• One account holder to the first account holder administering the detection: 1 • Administering account holder to a random trusted peer: 1

• Steps of account position detection: number of messages is approximately the account offset x • Response from trusted peer to administering account holder: 1

The sum of messages created results in: MP(k, x) = 3 + x Account Holder Set Locking

• The administering account holder to all other account holders: k − 1 • The other account holders to all other account holders: (k − 1)(k − 1)

• All other account holders confirm to the administrating account holder: k − 1 The sum of messages created results in: ML(k) = 2(k − 1) + (k − 1)2.

Account Holder Set Un-Locking

• The administering account holder to all other account holders: k − 1 Account Consistency

• One account holder to the account holder administering the process: 1 • The administering account holder to all other account holders: k − 1 • The other account holders to all other account holders: (k − 1)(k − 1)

• All other account holders confirm to the administrating account holder: k − 1 The sum of messages created results in: MC = 2k + (k − 1)2− 1.

Account Movement

• Account holder to the new first account holder position: 1 • Forward to other new account holders: k

• From new last account holder to all other new account holders: k − 1 • From new first account holder to all old holders: k

The sum of messages created results in: MM(k) = 3k Graceful Account Handover

• Leaving account holder to last account holder: 1 • Last account holder to new account holder: 1 • Response of new holder to leaving holder: 1 • Transfer of account data: 1

• Confirm transfer: 1

5.3.2.2 Joint Mechanisms Analysis

If one of the main maintenance mechanisms (detection of replica number or detection of new account holder set) comes to the conclusion that the account holder set must be repaired, a sequence of mecha- nisms is executed.

Account Replica Repair

Repairing the replica number of an account holder set requires running detection of the replica number, account holder set locking, account consistency, add account holder, and account holder set unlocking. This sequence of mechanisms results in:

MRR(k) = 2(k − 1)2+ 7k

Account Position Repair

Repairing an account holder sets position requires to run detection of correct account position, account holder set locking, account consistency, move account, account holder set unlocking. This sequence of mechanisms results in:

MP R(k, x) = 2(k − 1)2+ 8k − 1 + x