All nodes of a team (peers and splitter) that implements only the DBS transmitt exactly the same amount of media, which basically implies that if a peer can not fulfill this requirement it will be thrown of the team. Unfortunately, this could be considered too much demanding in some specific configurations, such as a team of colleagues that want to share a content regardless of who spends more transmission bandwidth, or in PPV (Pay-Per-View) systems where the stream must be guaranteed to those users that have paid for receiving the stream.
The number of chunks that ultimately a peer must retransmit depends exclusively on the number of chunks that the peer receives from the splitter. Besides, the splitter knows the performance of the peers of the team for the task of retransmitting the chunks by checking the number of times that the peers has lost a chunk (see Section 4.7). This knowledgment could be exploited by the splitter to maximize the profiting of the team capacity by assigning a different splitter-chunk-rate∗ ∗The number of chunks per second that the splitter sends to a peer. to the peers depending on their reliability. In other words, if a peer does not loss chunks, then its splitter-chunk-rate will be increased and viceversa. Now, lets classify the peers into two types: (1) class-A peers that contribute more and (2) class-B peers that contribute less.
By default and using only the ACS, the splitter-chunk-rate per peer will be the same for all peers if the team size remains constant. In this framework, the ACS proposes an adaptive Round-Robing scheduler (at the splitter, see Rule 1) in which the team cicle of a peer is proportional to the packet loss ratio of . Using the ACS, a class-A peer will receive from the splitter more chunks than a class-B peer and therefore, a class-A peer will enter in the burst mode (see Rule 3) more often than a class-B peer. This is something that goes against the throughtput of the class-A peer and that, in some moment, could produce a lost of chunks (remember the the burst mode can congest the upload link of the peers). Therefore, the throughtput of a class-A peer will grow until reachint its congestion threshold, instant in which the monitors peers will report the lost of this class-A peer and the splitter will decrease its splitter-chunk-rate.
Another consecuence of implementing the ACS is that class-A peers will remove from their list of peers to class-B peers more often, with a frequency that depends on among other things of the MAX_LOSS_COUNTER† †Each peer has a counter for each other peer of the team. This counter is increased when a chunk is sent to the peer and decreased when a chunk is received from that peer. If this counter is higher than MAX_LOSS_COUNTER, the unsupportive peer is removed from the list of peers (move this to DBS). configuration parameter of each peer. However, this action has not a noticeable impact on the performance of the team because the time that lasts from a class-A peer removes a class-B peer of its list of peers is smaller than the time that the class-B peer needs to send a chunk to the class-A peer, and when this happens, the class-B peer is inserted again in the list of peers of the class-A peer, reseting its loss counter. Anyway, an increment of the MAX_LOSS_COUNTER in class-A peers would improve the performance of the system.