This set of rules been designed to be eﬃcient in transmitting a data-stream from a splitter node to peers in the network when unicast transmissions are used between the nodes of the team.
- Chunk scheduling: Chunks are transmitted from the splitter to
peers, then among peers (see Figure ??). The splitter sends the
to the peer
being the number of peers in the team. Next, must forward this chunk to the rest of peers of the team. Chunks received from other peers are not retransmitted.
- Congestion avoidance in peers: Each peer sends chunks using a constant bit-rate strategy to minimize the congestion of its uploading link. Notice that the rate of chunks that arrive to a peer is a good metric to perform this control in networks with a reasonable low packet loss ratio.
- Burst mode in peers: The congestion avoidance mode is immediately abandoned if a new chunk has been received from the splitter before the previous chunk has been retransmitted to the rest of peers of the team. In the burst mode the peer sends the previously received chunk from the splitter to the rest of peers of the team as soon as possible. In other words, the peer sends the previous chunk to the rest of peers of the list (of peers) as faster as it can. Notice that although this behaviour is potentially a source of congestion, it is expectable a small number of chunks will be sent in the burst mode under a reasonable low packet loss ratio.
- The list of peers: Every node of the team (splitter and peers) knows the endpoint of the rest of peers in the team. A list is built with this information which is used by the splitter to send the chunks to the peers and is used by the peers to forward the received chunks to the other peers.
- Peer arrivals: An incoming peer
must contact with the splitter in order to join the team. After that, the splitter sends to
the list of peers
and the current∗
stream header over the TCP. More exactely, the splitter does:
- Send (over TCP) to the number of peers in the list of peers.
- For each peer
in the list of peers:
- Send (TCP) to the endpoint.
- Append to the list of peers.
In incomming peer performs:
- Receive (TCP) from the number of peers in the list of peers.
- For each peer
in the list of peers:
- Receive (TCP) end endpoint fron the splitter.
- Send (UDP) to a [hello] message.
Because the [hello] messages can be lost, some peer of the team could not know in this presentation. However, because peers also learh about their neighbors when a [IMS] message is received, the impact of these lost should be small.
- Free-riding control in peers: The main idea behind the DBS is that in a large enough
interval of time, any peer must relay the same amount of data that it receives. If a
(infra-solidary) peer can not enforce this rule, it must leave the team and join
another team that requires less bandwidth. In order to achieve this, each peer
assigns a counter to each
other peer of the team.
When a chunk is sent to ,
is incremented and when a chunk is received from it,
is decremented. If
reaches a given threshold,
is deleted from the list of
peers pf and it will not
be served any more by .
Notice that this rule will remove from the peer’s lists those peers that perform a impolite churn (those peers that leave the team without sending the [goodbye] message).
- Monitor peers: Some peers (see
in Figure 3), which usually run close (in hops) the splitter, play diﬀerent roles
depending on the P2PSP modules implemented. Among others:
- As a consequence of the impolite churn and peer insolidarity, it is unrealistic to think that a single video source can feed a large number of peers and simultaneously to expect that the users will experience a high QoS. For this reason, the team adminitrator should monitorize the streaming session because, if the media is correctly played by the monitor peer, then there is a high degree of probability that the peers of the team are correctly playing the media too.
- At least one monitor peer is created before any other peer in the team
and for this reason the transmission rate of the ﬁrst monitor peer is
However, the transmission rate of the second (ﬁrst standard) peer, and the
monitor peer, is:
where is the average encoding rate of the stream. When the size of the team is , the transmission rate of all peers (included the monitor peers, obviously) of the team is:
Therefore, only the ﬁrst (monitor) peer is included in the team without a initial transmission requirement. Notice also that
which means that when the team is large enough, all the peers of the team will transmitt the same amount of data that they receive.
- In order to minimize the number of loss reports (see Rule 10) Section 4.7) in the team, the monitor peers are the only entities allowed to complain to the splitter about lost chunks.
- Peer departures: Peers are required to send a [goodbye] message to the splitter
and the rest of peers of the team when they leave the team, in order the splitter
can stop sending chunks to them as soon as possible. However, if a peer
leaves without notiﬁcation no more chunks will be received from it. This should
trigger the following succession of events:
- In the rest of peers , the free-riding control mechanism (see Rule ??) will remove from the list of peers.
- All monitor peers will complain to the splitter about chunks that the splitter has sent to .
- After receiving a suﬃcient number of complains, the splitter will delete from his list.
- Relation between the buﬀer size
team size :
As in the IMS module, peers need to buﬀer some chunks before the playback.
However, the main reason of buﬀering in the DBS is not the network jitter but
the overlay jitter. As it has been deﬁned in Rule 1, peers retransmit the
[IMS] messages received from the splitter to the rest of the team. Also, it
has been speciﬁed in Rule 2 that peers send these messages using the
chunk-rate of the stream. Therefore, depending on the position of a peer
in the list of
peers of the peer ,
it can last more or less chunk times for
sending the [IMS]
message to .
In order to handle this unpredictable retransmission delay, the peer’s buﬀers should store at least chunks. This means that, the team size is limited by the buﬀer size, i.e., in the DBS module it must be hold that
- Chunk tracking at the splitter: In order to identify unsupportive peers (free-riding), the splitter remembers the numbers of the sent chunks to each peer among the last chunks. Only the monitor peers will complain about lost chunks to the splitter using [lost chunk number ] complain report messages. In the DBS module, a chunk is clasiﬃed as lost when it is time to send it to the player and the chunk is missing.
- Free-riding control in the splitter: In this module it is compulsory that peers contribute to the team the same amount of data they receive from the team (always in the conditions imposed by the Equation 4). In order to guarantee this, the splitter counts the number of complains (sent by the monitor(s) peer(s)) that a peer produces, for all the peers of the team. If this number exceeds a given threshold, then the unsupportive peer will be rejected from the team, ﬁrst removed from the list of the splitter and next from the lists of all peers of the team (see 6.