Dandelion: Cooperative Content Distribution with Robust Incentives

Dandelion: Cooperative Content Distribution with Robust IncentivesMichael Sirivianos Xiaowei Yang Stanislaw Jarecki

Presented byVidya Nalan Chakravarthy

ContentsIntroductionDesignOverviewRobust incentivesCredit managementUnauthorized content distributionPreliminary evaluationImplementationExperimental resultsConclusions

MotivationCost efficient solution to handle demand peaks

Robust incentives for client co-operation

Discourage unauthorized content exchange3Online Content DistributionIssueCost effective solution to handle peak usageOver-provisioning

SolutionsContent Distribution networks Free CDNsDandelion

4Online Content Distribution SolutionsContent distribution networks Example: AkamaiServices are costly

Free CDNsExamples: Coral, CoDeen and Cob-WebLack viable model to scale

Online Content Distribution SolutionsDandelionCost effective solution to handle flash crowdsUtilizes clients bandwidthRedirects requests to other clients with the contentOnline Content Distribution Solutions

Flash crowd scenarioDandelion ServerServerPeer-serving modeBitTorrent Vs Dandelion`BitTorrent uses rate based tit for tatSusceptible to manipulationNo motivation to upload after completion of download

No incentives for uploading in BitTorrent

DesignOverview

Robust Incentives

Credit Management

Discouraging unauthorized content distributionOverviewDandelion serverDistributes small and large static files

Responds to client requests with content

Enters peer-serving mode when overloadedRedirects requests to other clients with the content

Maintains virtual economyRobust incentivesCredits used for future downloads11Data Distribution (I)Server splits data into chunks

Chunks are disseminated independently

Allows clients to upload on receipt of a chunkIncreases efficiency of distribution pipelineIncentivizes clients to upload chunks to earn credits for downloading other missing chunksChunk1Chunk 2Chunk3Data Distribution (II)

Dandelion ServerChunk 1Chunk 2Chunk 1Chunk 2Chunk 3Chunk 3Robust IncentivesKey challengesPrevent client cheating Client does not upload any dataClient uploads garbage and claims credit

Maintain low processing and bandwidth costs

15SolutionCryptographic fair exchange mechanism

Dandelion server mediates exchanges

Non repudiable complaint mechanism16Peer serving protocolClients have password protected accounts with serverestablish a secure channel to obtain shared session keys

Message exchange during a flash crowd event is as shown:

17 Peer serving protocolStep 1:

1

Client B sends request to server

18Peer serving protocolStep2:

12

19Peer serving protocolStep 3:

123

20Peer serving protocolStep 4:

1234

21Peer serving protocolStep 5:

123,54

22Peer serving protocolStep 6:

123,54,6

23Peer serving protocolStep 7:

1,723,54,6

24Peer serving protocolStep 8:

1,72,83,54,6

25Peer serving protocolAs commitment does not verify due toTransmission error orA misbehaving orB misbehavingServer warns B and does not return encryption key kIt does not update As or Bs creditB re-requests the chunk from A or another clientPeer serving protocolIf B receives repeated invalid commitments from A, it should disconnect from A and blacklist it

If server receives repeated decryption requests from B with invalid commitments from A, B is blacklistedPeer serving protocol

Complaint MechanismIf decrypted file is invalid, B complains to the server

Complaint message containsAs commitmentDigest of the encrypted chunkEncryption of key k

A cannot repudiate it

Complaint MechanismIf commitment verifiesServer checks if commitment is computed over a valid chunkIf it does not verify, A is misbehaving

If commitment does not verifyB is misbehaving

Credit ManagementCredit Management Clients spend c > 0

Clients earn r > 0

To prevent colluders from increasing sum of their credit, c = rCredit Management Users with paid accountsUser purchases initial creditContent provider redeems credit for monetary rewardsMotivates client to upload to earn credit

Accounts without monetary transactionsNew clients are given a portion of creditAccumulates credits for uploading33Multiple registrationBoosting credit by registering multiple times

Not an issue with paid accountsUser purchases initial credit

Issue in free content distributionSybil attacks similar to Farsite and PasticheRequires a registration process 34Discourage unauthorized content distributionUnauthorized content distributionUploading to unauthorized usersNo strong incentivesServer can refrain giving credit to unauthorized usersVerify legitimacy of requestsAvoid wasting bandwidth on unauthorized users

Clients are held responsible for uploading to unauthorized users

Preliminary EvaluationPrototype Implementation

Experimental ResultsPrototype ImplementationCryptographic operationsOpenssl C library

Credit management system Database engine of Sqlite library

Architecture - combination ofAsymmetric Multi Process Event Driven ArchitectureStaged Event Driven ArchitectureDatabase OperationsMain thread reads request from network

sends requests to disk access or database access helper threads

Helper thread finishes and sends requests to another thread pool

Use zero-copy sendfile() for chunk transmission

39Network Operationsuse TCP

are asynchronous

are executed by thread processing the last stage of the request

Design features:Exploits parallelism

Good performance with both small and large files

number of concurrent connections/pending requests are kept separate from number of threads that can be handled by the OSExperimental resultsServer tasks in a flash crowd event1. Process key decryption requestsOne HMAC operation and block cipher decryptionOne query and two updates on credit databaseTransmits decryption key2. Send short responses

Types of client requestsRequest for decryption keysRequests for file chunks directly from server

42Server OperationsCryptographic operations are highly efficientSymmetric encryption is cheapBottleneck download link

43Client OperationsClients processing overhead does not affect its upload or download throughput

44Peer serving mode

45ResultsSmaller chunk size reduces performance gainmore load on the server due to decryption key requests

Cost of complaining is higherInvolves reading chunk, encrypting, hashingCost is not incurred repeatedlyMisbehavers are blacklistedConclusionsContributions:Robust incentivesDiscouraging unauthorized peersCan be used for copyright-protected digital goodsDrawbacks of DandelionLess efficient than BitTorrent tracker Less scalable than BitTorrentDistribute dandelion server and credit banks over multiple trusted nodes to improve scalability47Thank You!