P2P Applications - Peer-to-Peer Computing: Applications, Architecture, Protocols, and Challenges - page 15

Skype is robust not only in the aspect of its ability to route tra c around
NATs or firewalls, but also in its lean requirements on bandwidths. Specifi-
cally, for voice tra c flows, typically the total uplink and downlink bandwidth
required is only around 40 kbps.
One key aspect about the protocol and architecture of Skype is that users
cannot possibly (as of this writing) refuse to be a super-node. Indeed, when the
Skype client program discovers that the client's machine is powerful enough
in terms of machine architecture, bandwidth available, whether it is behind a
firewall or NAT, etc., the client machine could be “promoted” to be a super-
node. This enforcement of super-node role could be a potential problem for
the robustness of Skype as there is not enough incentive provided for a client
machine to serve as a super-node.
When there are multiple parties in a VoIP session, i.e., a conferencing sit-
uation, the system needs to carry out a “mixing” operating—merging several
streams of voice packets for delivery to the receivers. There are several pos-
sible approaches [Gu et al., 2008] to achieve this. For example, as shown in
Figure 2.2(a), each sender (i.e., a speaker in the conferencing session) uses a
separate multicast tree for sending voice packets to the receivers. Here, sender
A uses its own multicast tree to deliver packets to the receivers, and sender B
does the same independently. That is, the “mixing” action is accomplished by
each individual receiver. While this approach is straightforward in the sense
that existing multicasting infrastructure of each sender can be used indepen-
dently, the obvious drawback is that there is a need to maintain a potentially
large number of such trees.
Another approach is to designate one participant (or even a dedicated
server) to handle the mixing and the subsequent distribution, as shown in
Figure 2.2(b). This is a preferred design option in many commercial confer-
encing systems due to its ease of management. However, with a designated
node to handle the mixing and distribution, there is obviously a limit of how
many participants it can handle. Indeed, it is reported that even in Skype, the
system can only allow five simultaneous participants in a conferencing session.
Toward the other extreme is the approach that uses only one single multi-
cast tree throughout. That is, the same multicast tree is used for any sender
and all the mixing and distribution of packets, as illustrated in Figure 2.2(c).
Here, we have node A as the root of this unified multicast tree, and hence,
when A speaks, its packets are delivered along the tree to every other par-
ticipant. Now, the other speaker, node B, uses the same tree for its packets.
Specifically, when B sends its voice packets, it treats itself as the root of the
tree and thus, it transmits its packets to A, C, and F. At this point, the voice
packets of A and B are mixed along the tree edges AD, DE, BC, and BF.
More importantly, we can also see that there is a potential problem caused by
asymmetric incoming and outgoing bandwidths of each node. Consider node
B and we can see that it may not have su cient outgoing bandwidth (as in a
common ADSL situation) to support the mixing of packets from both A and