Universität Rostock1 A P2P network traffic and access control protocol Herwig Unger Albert – Einstein-Str. 23, 18051 Rostock, Germany Phone: +49 381 498

Universität Rostock 1

A P2P network traffic andaccess control protocol

Herwig UngerAlbert – Einstein-Str. 23, 18051 Rostock, Germany

Phone: +49 381 498 3365, Fax: +49 381 498 3366E-mail: [email protected]


Motivation

• decentralized P2P system recently gained an increasing popularity due to a lot of advantages

• communities are built on the base of such systems reflecting it its structures the social relations between ist users

• however, contents is offered only by a small group of users –e.g. 5% of all machines host 70% of all contents

• offering contents is not attractive for the users, since herebya lot of bandwidth is taken to answer remote user‘s request

• lurker and freerider mostly take advantage from such systems

Powerful control mechanisms are needed to control trafficand access of resources


Ideas: what can be done with virtual money

• Special services (not standard services like search) and information are only available for an additional payment.

• High priorities for the service execution are given for additional payment, since these priorities may cause shorter answer times.

• Bandwidth will be limited. Standard user communication is either done with a small percentage of the available communication

bandwidth or only available, if the network load is not to high.

• Hopcounters of message chains are lower for standard users. Therefore, standard users may not see the whole size of the network and cannot access to all available information.


Requirements to virtual money

1. An amount of money represented through tokens must be generated in the community.

2. The amount of money must be adapted to the number of community members and therefore the potential to offer services/resources in a community.

3. Fault tolerance and copy protection must be provided by decentralized algorithms.

4. Safe trading mechanisms must be described

Virtual money on the base of a token population shall be used with a respective transmission protocol


Building trust

• Trusted third authorities (machines)

• Duration of mutual relations + possibility to predict the other‘s behavior

• witnesses, control by a group of other machinese.g. trust chains


Control of the token amount f(community_member)

The number of tokens in the population can be controlled with a decentralized mechanism.

Every node generates and kills tokens depending on the average time between the visits of 2 tokens.

The existing number of tokens is an almost stable value over the time and depends from the number and characteristics of the community members.

Statistics of the token population


Statistics for the amount of money

Statistics – difference between token generation and removal for every node

Tokens removal means to destroy money, which is owned by one of the community members.

Even if the monetary value is small, too large lost / win by this process must be avoided.

Since the process is done pretty randomly, the „+“ and „-“ are well balanced for every node of the community over a linger time.


The token structure


The copy safe protocol for money token

Time

K=2

logical transfer

physical transfer by protocol

a) Forward (FWD) Protocol b) Token transmission realized by the protocol

Machine i Machine i-K (witness)

Machine i+K

FWD_witness

FWD_i+1

Acknowledge RCV

Acknowledge FWD

Acknowledge FWD_i+1


where is equal .

1. The probability that k nodes are active is

2. The probability that a machine is in the network is not equallydistributed over the whole day. It will be significantly higher a few moments after the time when it has been already seen in the network.

3. The exponential distribution can be used to model this stochastic lifetime problem.

4. If a computer ci has been a member of a community at time ti, the probability p(ci) that it is still connected with this community at time t'i (with ti < t'i) is given by

Analysis I

Kactivetp )

sec864001(1'

)'('

01)( ii

ii tttt

i edecp

activet

1


Analysis II

)())(1()()()( mKi

mi

mK

K

nm

cpcpnp

5. Therefore, the probability p(n) that at least n of K machines are available after some times is given by

K

nm mcs si siii cpcpnp

}1,....,1,0{

))(1()()(

mS

what can be estimated for equal, average transmission and processing times by

with

Ti ecp )(

30 machines are a good compromise


Fault tolerance

• In case the of no response of the owner node x, the token will be forwarded to the next node without replacing x for a fixed set of L cycles; i.e. in case x joins the community in this time again, it will still have access to its coin. After L cycles the money is assigned to any node from the history.

• If one other node i-K does not respond, i-(K-1) will be used instead.

All predecessors j in the history, j=i-(k-1) (1) i-1, will be put on position j-1 and for position i-1 a randomly selected, new node will be contacted and obtain the needed information of the token. For security reasons, this replacement can be done for limited number of nodes in the history, only. • Every owner of a token may keep a copy his tokens. In case one of

the tokens is not returned to its owner within a timeout interval, it may use the copy to contact all nodes kept in the history, find out the place of loss an re-initiate the respective token game.


1. The owner crypts his own and the IP address of the receiver (typically with its private key) and put it on the token.

2. The new owner is set as the successor of the old owner in the forward cycle.

3. The token pass another cycle over the new owner and K-2 randomly selected machines.

4. The machines along the history trail check the authenticity of the token and store the old and new owner information.

5. For a second cycle, the old owner adds again the new owner as its sucessor.

6. Now, the new owner replaces the two IP addresses attached by its own (crypted with its provate key), only. This change can be confirmed by the nodes of the history, since they do know both addresses from the last cycle.

7. The token forward will be continued with the new owner (i.e. a new node, where the token return to after K-1 steps).

Trading


Network traffic control

1. tokens are used.

2. the number of tokens will be controlled by all community members in a decentral manner, again.

3. the tokens are not used as money but as PERMIT to transfer messages or data ackages with a fixed size.

4. tokens use the before introduced protocol, messages / date may be sent directly.

5. from community members, only incoming messages authorized by tokens are accepted.


Conclusion

The introduced probabilistic money system may control access and traffic in P2P communities in a fair manner.

The user do not see the trading activities but the knowledge about its existence may force him to contribute resources.

The properties of the payment system differ from real money.

The developed protocol ensures probabilistically security and copy protection for the money tokens.

On top of a non-stable community a stable structure is built, which probably can be used for other applications, too.


Thank you for your attention !

Contact:Contact:

Herwig UngerFB Informatik, Universität RostockD-18051 Rostock

Email: [email protected]: +49 381 498-3355

Documents

Universität Rostock1 A P2P network traffic and access control protocol Herwig Unger Albert – Einstein-Str. 23, 18051 Rostock, Germany Phone: +49 381 498