Source: snapvoip.blogspot.com

I was surfing the web searching for information on Skype technology and if it affects users as popular beliefs on the net and else where. Specially in the case of Supernodes and relaying nodes, mentioned in the article;
VOIP IP Telephony: How to be or not to be a skype supernode?
I did find some very good information. One of the studies (the best in my view) were done by Saikat Guha of Cornell University and Neil Daswani, Ravi Jain of Google. The study was conducted over more than four months extending from September 1, 2005 to January 14, 2006. Also one factor that they state is that, Experiments on this data were done in a black-box manner, i.e., without knowing the internals or specifics of the Skype system or messages, as Skype encrypts all user traffic and signaling traffic payloads. The results indicate that although the structure of the Skype system appears to be similar to other P2P systems, particularly KaZaA, there are several significant differences in traffic. The number of active clients shows diurnal and work-week behavior, correlating with normal working hours regardless of geography. The population of supernodes in the system tends to be relatively stable; thus node churn, a significant concern in other systems, seems less problematic in Skype. The typical bandwidth load on a supernode is relatively low, even if the supernode is relaying VoIP traffic.
So is Skype good or bad? well you have to take all the facts and decide for your self.
Despite its popularity, little is known about Skype’s encrypted protocols and proprietary network. Garfinkel (His site has a wealth of information but the related article was found on another site Perhaps why the original authors just cited the article, I have uploaded the article to iptelephony at google groups.), concludes that Skype is related to KaZaA; both the companies were founded by the same individuals, there is an overlap of technical staff, and that much of the technology in Skype was originally developed for KaZaA. Network packet level analysis of KaZaA and of Skype (and again the article was uploaded to iptelephony at google groups) support this claim by uncovering striking similarities in their connection setup, and their use of a “supernode”-based hierarchical peer-to-peer network.

Supernode-based peer-to-peer networks organize participants into two layers: supernodes, and ordinary nodes. Such networks have been the subject of recent research. Typically, supernodes maintain an overlay network among themselves, while ordinary nodes pick one (or a small number of) supernodes to associate with; supernodes also function as ordinary nodes and are elected from amongst them based on some criteria. Ordinary nodes issue queries through the supernode(s) they are associated with.

Here are the two experiments;
Experiment..1:
Basic operation. We conducted an initial experiment to examine the basic operation and design of the Skype network in some more detail. We ran two Skype clients (version 1.1.0.13 for Linux) on separate hosts, and observed the destination and source IP addresses for packets sent and received in response to various application-level tasks. We observed that in Skype, ordinary nodes send control traffic including availability information, instant messages, and requests for VoIP and file-transfer sessions over the supernode peer-to-peer network. If the VoIP or file-transfer request is accepted, the Skype clients establish a direct connection between each other. To examine this further, we repeated the experiment for a single client behind a NAT2, and both clients behind different NATs. We observed that if one client is behind a NAT, Skype uses connection reversal whereby the node behind the NAT initiates the TCP/UDP media session regardless of which end requested the VoIP or file-transfer session. If both clients are behind NATs, Skype uses STUN-like NAT traversal to establish the direct connection. In the event that the direct connection fails, Skype falls back to a TURN-like approach where the media session is relayed by a publicly reachable supernode. This latter approach is invoked when NAT traversal fails, or a firewall blocks some Skype packets. Thus the overall mechanism that Skype employs to service VoIP and file transfer requests is quite robust to NAT and firewall reachability limitations.

Experiment..2:
Promotion to supernode. We next investigated how nodes are promoted to supernodes. In an experiment we conducted, we ran several Skype nodes in various environments and waited two weeks for them to become supernodes. A Skype node behind a saturated network uplink, and one behind a NAT, did not become supernodes, while a fresh install on a public host with a 10 Mbps connection to the Internet joined the supernode network within minutes. Consequently, it appears that Skype supernodes are chosen from nodes that have plenty of spare bandwidth, and are publicly reachable. This approach clearly favors the overall availability of the system. We did not test additional criteria such as a history of long session times, or low processing load as suggested in this article, p2p supernode. As we show later, the population of supernodes selected by Skype, apparently based on reachability and spare bandwidth, tends to be relatively stable. Skype, therefore, represents an interesting point in the P2P design-space where heterogeneity is leveraged to control churn, not just cope with it.

Well the article seems to be getting too long. I will have to make a second article to finish the rest. It will be interesting as you will be able to see all Skype info in visual format, i.e. graphs. I am sure it will be interesting.