Bar Gossip Aleksander Jurkowski University of Warsaw - - PowerPoint PPT Presentation

bar gossip
SMART_READER_LITE
LIVE PREVIEW

Bar Gossip Aleksander Jurkowski University of Warsaw - - PowerPoint PPT Presentation

Bar Gossip Aleksander Jurkowski University of Warsaw aj262944@students.mimuw.edu.pl October 18, 2010 Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 1 / 25 Introduction Goal Provide p2p data streaming system usable for live


slide-1
SLIDE 1

Bar Gossip

Aleksander Jurkowski

University of Warsaw aj262944@students.mimuw.edu.pl

October 18, 2010

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 1 / 25

slide-2
SLIDE 2

Introduction

Goal

Provide p2p data streaming system usable for live podcasts. There is no competitive solution so far...

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 2 / 25

slide-3
SLIDE 3

Introduction

Goal

Provide p2p data streaming system usable for live podcasts. There is no competitive solution so far...

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 2 / 25

slide-4
SLIDE 4

Motivation

Why BAR Gossip?

Benefitting from p2p systems robustness, scalability and adaptivity Shifting costs (e.g. bandwidth) to clients

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 3 / 25

slide-5
SLIDE 5

Motivation

Why BAR Gossip?

Benefitting from p2p systems robustness, scalability and adaptivity Shifting costs (e.g. bandwidth) to clients

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 3 / 25

slide-6
SLIDE 6

Key features

Difference from other solutions

provides stable, reliable throughput focuses on short intervals does not optimize overall download speed small amount of data at given time robust agains Byzantine and Rational clients no purely local, long term based reputation

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 4 / 25

slide-7
SLIDE 7

Key features

Difference from other solutions

provides stable, reliable throughput focuses on short intervals does not optimize overall download speed small amount of data at given time robust agains Byzantine and Rational clients no purely local, long term based reputation

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 4 / 25

slide-8
SLIDE 8

Key features

Difference from other solutions

provides stable, reliable throughput focuses on short intervals does not optimize overall download speed small amount of data at given time robust agains Byzantine and Rational clients no purely local, long term based reputation

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 4 / 25

slide-9
SLIDE 9

Vocabulary

BAR ?

Byzantine - arbitrary malitious client Altruistic - implementing protocol exactly as described Rational - self-serving client

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 5 / 25

slide-10
SLIDE 10

Vocabulary

BAR ?

Byzantine - arbitrary malitious client Altruistic - implementing protocol exactly as described Rational - self-serving client

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 5 / 25

slide-11
SLIDE 11

Vocabulary

BAR ?

Byzantine - arbitrary malitious client Altruistic - implementing protocol exactly as described Rational - self-serving client

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 5 / 25

slide-12
SLIDE 12

Security basis

Assumptions

Digital signatures - each of the clients signs sent messages Dynamic membership - non-Byzantine clients remain in the system until end of the broadcast Single identity for each of the clients

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 6 / 25

slide-13
SLIDE 13

Security basis

Assumptions

Digital signatures - each of the clients signs sent messages Dynamic membership - non-Byzantine clients remain in the system until end of the broadcast Single identity for each of the clients

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 6 / 25

slide-14
SLIDE 14

Security basis

Assumptions

Digital signatures - each of the clients signs sent messages Dynamic membership - non-Byzantine clients remain in the system until end of the broadcast Single identity for each of the clients

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 6 / 25

slide-15
SLIDE 15

Vocabulary

POM

Proof Of Misbehavior - a sequence of signed messages proving that a client violates the protocol

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 7 / 25

slide-16
SLIDE 16

Broadcast

Broadcast consists of rounds, each T + δ long T - time interval sufficient to complete message communication for

  • ne round

Update expires deadline rounds after being sent by broadcaster. It is delivered to the media player after expiration. The update is considered delivered timely when it is received before the deadline

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 8 / 25

slide-17
SLIDE 17

Broadcast

Broadcast consists of rounds, each T + δ long T - time interval sufficient to complete message communication for

  • ne round

Update expires deadline rounds after being sent by broadcaster. It is delivered to the media player after expiration. The update is considered delivered timely when it is received before the deadline

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 8 / 25

slide-18
SLIDE 18

Broadcast

Broadcast consists of rounds, each T + δ long T - time interval sufficient to complete message communication for

  • ne round

Update expires deadline rounds after being sent by broadcaster. It is delivered to the media player after expiration. The update is considered delivered timely when it is received before the deadline

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 8 / 25

slide-19
SLIDE 19

Broadcast

Broadcast consists of rounds, each T + δ long T - time interval sufficient to complete message communication for

  • ne round

Update expires deadline rounds after being sent by broadcaster. It is delivered to the media player after expiration. The update is considered delivered timely when it is received before the deadline

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 8 / 25

slide-20
SLIDE 20

Connecting to the broadcast

Client generates a session public and private key Client sends the keys to the broadcaster Broadcaster verifies the keys Broadcaster publishes a list of clients (identity, address, public key)

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 9 / 25

slide-21
SLIDE 21

Connecting to the broadcast

Client generates a session public and private key Client sends the keys to the broadcaster Broadcaster verifies the keys Broadcaster publishes a list of clients (identity, address, public key)

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 9 / 25

slide-22
SLIDE 22

Connecting to the broadcast

Client generates a session public and private key Client sends the keys to the broadcaster Broadcaster verifies the keys Broadcaster publishes a list of clients (identity, address, public key)

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 9 / 25

slide-23
SLIDE 23

Connecting to the broadcast

Client generates a session public and private key Client sends the keys to the broadcaster Broadcaster verifies the keys Broadcaster publishes a list of clients (identity, address, public key)

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 9 / 25

slide-24
SLIDE 24

Round

Broadcaster sends the update to nSeeds randomly selected clients nSeeds must be high enough for at least one non-Byzantine client to receive the update Every client cannot receive the update from the broadcaster, delivery to the rest is based on protocols:

Balanced Exchange Optimistic Push

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 10 / 25

slide-25
SLIDE 25

Round

Broadcaster sends the update to nSeeds randomly selected clients nSeeds must be high enough for at least one non-Byzantine client to receive the update Every client cannot receive the update from the broadcaster, delivery to the rest is based on protocols:

Balanced Exchange Optimistic Push

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 10 / 25

slide-26
SLIDE 26

Round

Broadcaster sends the update to nSeeds randomly selected clients nSeeds must be high enough for at least one non-Byzantine client to receive the update Every client cannot receive the update from the broadcaster, delivery to the rest is based on protocols:

Balanced Exchange Optimistic Push

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 10 / 25

slide-27
SLIDE 27

Balanced Exchange

The idea

The updates are traded one by one, meaning that each of the clients sends exactly the same number of updates.

Problems

This protocol itself is insufficient for unlucky (rarely chosen by broadcaster) or facing network failures clients.

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 11 / 25

slide-28
SLIDE 28

Balanced Exchange

The idea

The updates are traded one by one, meaning that each of the clients sends exactly the same number of updates.

Problems

This protocol itself is insufficient for unlucky (rarely chosen by broadcaster) or facing network failures clients.

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 11 / 25

slide-29
SLIDE 29

Optimistic push

Push

In Optimistic Push the client can send more updates than he receives, allowing the fallen behind client to get the data.

Optimistic

This mechanism is considered optimistic because it is based on hope that the benefitting client will do the same favor in return later. Such behavior is not enforced by the protocol.

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 12 / 25

slide-30
SLIDE 30

Optimistic push

Push

In Optimistic Push the client can send more updates than he receives, allowing the fallen behind client to get the data.

Optimistic

This mechanism is considered optimistic because it is based on hope that the benefitting client will do the same favor in return later. Such behavior is not enforced by the protocol.

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 12 / 25

slide-31
SLIDE 31

Balanced Exchange and Optimistic Push

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 13 / 25

slide-32
SLIDE 32

Choosing partner for Balanced Exchange

1 Client S seeds the PRNG (Pseudo Random Number Generator) with

the signature <r, BAL>S, where r is the round number

2 The numbers generated by the PRNG is deterministically mapped

into client ids until S a first partner without an eviction notice - R

3 S sends the seed and the list of eviction notices to R 4 R validates the data:

The seed is a valid signature r is the current round number All supplied eviction notices are valid The seeded PRNG generates R as the first non-evicted client The seeded value has never been presented to R by S

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 14 / 25

slide-33
SLIDE 33

Choosing partner for Balanced Exchange

1 Client S seeds the PRNG (Pseudo Random Number Generator) with

the signature <r, BAL>S, where r is the round number

2 The numbers generated by the PRNG is deterministically mapped

into client ids until S a first partner without an eviction notice - R

3 S sends the seed and the list of eviction notices to R 4 R validates the data:

The seed is a valid signature r is the current round number All supplied eviction notices are valid The seeded PRNG generates R as the first non-evicted client The seeded value has never been presented to R by S

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 14 / 25

slide-34
SLIDE 34

Choosing partner for Balanced Exchange

1 Client S seeds the PRNG (Pseudo Random Number Generator) with

the signature <r, BAL>S, where r is the round number

2 The numbers generated by the PRNG is deterministically mapped

into client ids until S a first partner without an eviction notice - R

3 S sends the seed and the list of eviction notices to R 4 R validates the data:

The seed is a valid signature r is the current round number All supplied eviction notices are valid The seeded PRNG generates R as the first non-evicted client The seeded value has never been presented to R by S

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 14 / 25

slide-35
SLIDE 35

Choosing partner for Balanced Exchange

1 Client S seeds the PRNG (Pseudo Random Number Generator) with

the signature <r, BAL>S, where r is the round number

2 The numbers generated by the PRNG is deterministically mapped

into client ids until S a first partner without an eviction notice - R

3 S sends the seed and the list of eviction notices to R 4 R validates the data:

The seed is a valid signature r is the current round number All supplied eviction notices are valid The seeded PRNG generates R as the first non-evicted client The seeded value has never been presented to R by S

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 14 / 25

slide-36
SLIDE 36

Choosing partner for Balanced Exchange

1 Client S seeds the PRNG (Pseudo Random Number Generator) with

the signature <r, BAL>S, where r is the round number

2 The numbers generated by the PRNG is deterministically mapped

into client ids until S a first partner without an eviction notice - R

3 S sends the seed and the list of eviction notices to R 4 R validates the data:

The seed is a valid signature r is the current round number All supplied eviction notices are valid The seeded PRNG generates R as the first non-evicted client The seeded value has never been presented to R by S

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 14 / 25

slide-37
SLIDE 37

Choosing partner for Balanced Exchange

1 Client S seeds the PRNG (Pseudo Random Number Generator) with

the signature <r, BAL>S, where r is the round number

2 The numbers generated by the PRNG is deterministically mapped

into client ids until S a first partner without an eviction notice - R

3 S sends the seed and the list of eviction notices to R 4 R validates the data:

The seed is a valid signature r is the current round number All supplied eviction notices are valid The seeded PRNG generates R as the first non-evicted client The seeded value has never been presented to R by S

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 14 / 25

slide-38
SLIDE 38

Choosing partner for Balanced Exchange

1 Client S seeds the PRNG (Pseudo Random Number Generator) with

the signature <r, BAL>S, where r is the round number

2 The numbers generated by the PRNG is deterministically mapped

into client ids until S a first partner without an eviction notice - R

3 S sends the seed and the list of eviction notices to R 4 R validates the data:

The seed is a valid signature r is the current round number All supplied eviction notices are valid The seeded PRNG generates R as the first non-evicted client The seeded value has never been presented to R by S

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 14 / 25

slide-39
SLIDE 39

Choosing partner for Balanced Exchange

1 Client S seeds the PRNG (Pseudo Random Number Generator) with

the signature <r, BAL>S, where r is the round number

2 The numbers generated by the PRNG is deterministically mapped

into client ids until S a first partner without an eviction notice - R

3 S sends the seed and the list of eviction notices to R 4 R validates the data:

The seed is a valid signature r is the current round number All supplied eviction notices are valid The seeded PRNG generates R as the first non-evicted client The seeded value has never been presented to R by S

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 14 / 25

slide-40
SLIDE 40

History Exchange

History

A set of the updates ids

Exchange

1 In the first message S sends i.a. a hash of its history - #HS 2 R verifies if it is allowed to communicate with S and sends its history

  • HR

3 S sends its history to R 4 R verifies if the previously sent hash is consistent with the provided

history

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 15 / 25

slide-41
SLIDE 41

History Exchange

History

A set of the updates ids

Exchange

1 In the first message S sends i.a. a hash of its history - #HS 2 R verifies if it is allowed to communicate with S and sends its history

  • HR

3 S sends its history to R 4 R verifies if the previously sent hash is consistent with the provided

history

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 15 / 25

slide-42
SLIDE 42

History Exchange

History

A set of the updates ids

Exchange

1 In the first message S sends i.a. a hash of its history - #HS 2 R verifies if it is allowed to communicate with S and sends its history

  • HR

3 S sends its history to R 4 R verifies if the previously sent hash is consistent with the provided

history

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 15 / 25

slide-43
SLIDE 43

History Exchange

History

A set of the updates ids

Exchange

1 In the first message S sends i.a. a hash of its history - #HS 2 R verifies if it is allowed to communicate with S and sends its history

  • HR

3 S sends its history to R 4 R verifies if the previously sent hash is consistent with the provided

history

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 15 / 25

slide-44
SLIDE 44

Update Exchange

1 S and R exchange k most recent updates the other client lack in

signed briefcases containing:

The seed identifying the exchange Plaintext description of the update ids Updates encrypted with #(Kpriv

S

, seed)

2 R and S verify the received messages:

if the briefcase seed number matches the exchange seed if the briefcase updates list matches the expected one

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 16 / 25

slide-45
SLIDE 45

Update Exchange

1 S and R exchange k most recent updates the other client lack in

signed briefcases containing:

The seed identifying the exchange Plaintext description of the update ids Updates encrypted with #(Kpriv

S

, seed)

2 R and S verify the received messages:

if the briefcase seed number matches the exchange seed if the briefcase updates list matches the expected one

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 16 / 25

slide-46
SLIDE 46

Update Exchange

1 S and R exchange k most recent updates the other client lack in

signed briefcases containing:

The seed identifying the exchange Plaintext description of the update ids Updates encrypted with #(Kpriv

S

, seed)

2 R and S verify the received messages:

if the briefcase seed number matches the exchange seed if the briefcase updates list matches the expected one

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 16 / 25

slide-47
SLIDE 47

Key Exchange

Client behavior

Client sends a key request via UDP containing the exchange seed as well as responds to key requests Key respond contains:

the exchange seed value desryption key for prevoiusly received briefcase of updates

Ommiting the phase

If a client receives a briefcase but not the decription key, then the messages constitute a suspected POM

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 17 / 25

slide-48
SLIDE 48

Key Exchange

Client behavior

Client sends a key request via UDP containing the exchange seed as well as responds to key requests Key respond contains:

the exchange seed value desryption key for prevoiusly received briefcase of updates

Ommiting the phase

If a client receives a briefcase but not the decription key, then the messages constitute a suspected POM

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 17 / 25

slide-49
SLIDE 49

Key Exchange

Client behavior

Client sends a key request via UDP containing the exchange seed as well as responds to key requests Key respond contains:

the exchange seed value desryption key for prevoiusly received briefcase of updates

Ommiting the phase

If a client receives a briefcase but not the decription key, then the messages constitute a suspected POM

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 17 / 25

slide-50
SLIDE 50

Filling POMs

Balanced Exchange

Given a client provides different data than described in history exchange it is a base of a POM.

Constructing the POM

Each of the messages the client receives is signed by the sender and has a hash of the previous one. With this information, together with the received data, we can easily show prove that the protocol was violated by this particular client (signature) and the order of messages (previous message hash).

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 18 / 25

slide-51
SLIDE 51

Filling POMs

Balanced Exchange

Given a client provides different data than described in history exchange it is a base of a POM.

Constructing the POM

Each of the messages the client receives is signed by the sender and has a hash of the previous one. With this information, together with the received data, we can easily show prove that the protocol was violated by this particular client (signature) and the order of messages (previous message hash).

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 18 / 25

slide-52
SLIDE 52

Auditor

The auditor is an agent prompting randomly chosen clients for POMs against other clients. If the client does not have any POMs he has to send a dummy message. The POM query responses are of equal size so omitting POMs does not save any bandwidth Clients not responding to auditor queries are considered Byzantine and removed

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 19 / 25

slide-53
SLIDE 53

Auditor

The auditor is an agent prompting randomly chosen clients for POMs against other clients. If the client does not have any POMs he has to send a dummy message. The POM query responses are of equal size so omitting POMs does not save any bandwidth Clients not responding to auditor queries are considered Byzantine and removed

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 19 / 25

slide-54
SLIDE 54

Auditor

The auditor is an agent prompting randomly chosen clients for POMs against other clients. If the client does not have any POMs he has to send a dummy message. The POM query responses are of equal size so omitting POMs does not save any bandwidth Clients not responding to auditor queries are considered Byzantine and removed

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 19 / 25

slide-55
SLIDE 55

Auditor

The auditor is an agent prompting randomly chosen clients for POMs against other clients. If the client does not have any POMs he has to send a dummy message. The POM query responses are of equal size so omitting POMs does not save any bandwidth Clients not responding to auditor queries are considered Byzantine and removed

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 19 / 25

slide-56
SLIDE 56

BAR Gossip reliability

Circumstances BAR Gossip prototype deals with

Robust against Byzantine and selfish behavior even if 40% of rational clients collude Manages deliver the updates timely in an environment where 20% of the clients are Byzantine and the rest is rational

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 20 / 25

slide-57
SLIDE 57

BAR Gossip reliability

Circumstances BAR Gossip prototype deals with

Robust against Byzantine and selfish behavior even if 40% of rational clients collude Manages deliver the updates timely in an environment where 20% of the clients are Byzantine and the rest is rational

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 20 / 25

slide-58
SLIDE 58

Test - probability of receiving an update

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 21 / 25

slide-59
SLIDE 59

Test - average upload bandwidth

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 22 / 25

slide-60
SLIDE 60

Test - probability of receiving an update

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 23 / 25

slide-61
SLIDE 61

References

Harry C. Li, Allen Clement, Edmund L. Wong, Jeff Napper, Indrajit Roy, Lorenzo Alvisi, Michael Dahlin (2006) BAR Gossip.

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 24 / 25

slide-62
SLIDE 62

The End

Aleksander Jurkowski (MIM UW) Bar Gossip October 18, 2010 25 / 25