🎗️Combine protocols

Combine protocols

The The Open System protocol uses a sharing algorithm called “tit-for-tat”, which is implemented using a mechanism called “choking.” The Open System clients classify peers as either choked or unchoked. An example choking algorithm might sort peers based on how much data the client has received from each one since the choking algorithm was last executed. The first n peers (where n is the number of unchoke slots, a fixed value chosen by each client) are classified as unchoked and the rest as choked.

Only unchoked peers are eligible to receive data. The choke state of all peers is recalculated periodically (typically every 15 seconds). Seeds do not receive any data from peers, so they use the amount of data sent to each peer to determine which peers are eligible to be unchoked in the next round. This means seeds optimize for maximum throughput, with no regard for any other factor.

There is also a separate choking algorithm called “optimistic unchoking” which uses a number of reserved unchoke slots (typically one). Optimistic unchoking selects a peer to unchoke in a random or round-robin fashion. This allows new peers an opportunity to receive some data so that they can start reciprocating with other peers.

Choking is the primary means of allocating resources within a The Open System swarm. The Open System Speed will extend this mechanism so that a service provider will include both TOS bid data and peer upload rate in its decisions about which peer to unchoke.

How this inclusion takes places will vary depending on how the client’s choking algorithm is implemented. When it comes time for the client to run its choking algorithm, it first compiles a list of eligible bids. The example algorithm described above could be modified to sort peers by a combination of highest eligible bid and most data received.

When an eligible bidder is unchoked, the service provider will send a new The Open System protocol extension bid response message to the bidder containing the rate in TOS/byte the bidder is expected to pay. This message will be followed by a normal unchoke message.

Clients may implement any auction format, but a variant of the Vickrey-Clarke-Groves auction is expected to produce optimum results. See Figure 2 for an outline of the auction mechanics, which ends up being a multi-unit uniform price auction.

Each service requester bids on only one unchoke slot per service provider. Clients would charge each unchoked bidder the rate of the highest losing bid.

Figure 2. Auction mechanics of a multi-unit uniform price auction

Caution must be exercised when dealing with optimistic unchoking due to its importance in allowing new peers to bootstrap into the swarm. The optimistic unchoke slot(s) should not be subject to the same auction format as the regular unchoke slots. If the client is using a round-robin algorithm for optimistic unchoking, it should only apply an auction to break ties between peers which have gone the same amount of time since being choked. This means auctioning of the optimistic unchoke slot will typically only happen between bidders that have never been unchoked.

In swarms with both TOS-enabled The Open System clients and legacy The Open System clients, service requesters will be able to offer TOS to service providers. However, upload speeds from legacy The Open System clients will be maximized without regard for any TOS token bids.