NNSquad - Network Neutrality Squad
[ NNSquad ] Re: Economics of P2P (was Re: Re: Net Neutrality vs.Illegal Acts)
Let me first begin by saying that you all are being trapped by someone's disingenuous straw-man argument. Today's P2P protocols have no features or functions to provide anonymity -- nothing at all. It was not designed to do that. Remember, these protocols were all written when ISPs provided last-mile connectivity to the Internet. At that time, ISPs weren't considered "the man in the middle" -- they were supposed to be working for us -- providing us connectivity to the Internet. BitTorrent started lightly encrypting its streams only 2-3 years ago -- not for anonymity, but to prevent interference. No features have ever been added for anonymity. > P2P data transfer can be used for legitimate purposes. In this case > it is massive cost shifting and far less economically efficient > overall, but its still legitimate usage. Far less economically efficient -- less than what? Take BitTorrent (P2P's most popular protocol by far): Less than ... An FTP transfer from a single host? no. Less than ... A localized data center (such as Limelight or Akamai)? no -- BitTorrent's optimistic-unchoking method is designed to ensure efficient peering. Less than ... P4P? My theory is no -- P4P sounds like a different method of efficient peering, but not necessarily more efficient. Optimistic unchoke should give similar results as P4P's AS-aware method does. > IF said P2P protocols were "super friendly", that is, friendlier than > TCP, ALL P2P networks transport data over TCP. Therefore, by definition, they can't make TCP more aggressive than it is. Furthermore, all P2P clients have additional congestion controls built in -- and even more options that are available. > really only using unused bandwidth rather than filling the pipe > (and resulting in congestion), Nick, there is no difference between the two. All Window's based TCP applications talk to Windows Sockets. You tell it to open a socket to IP:PORT and you tell it what to send. "Filling the pipe" is not something that P2P does or doesn't do. It's something that TCP does and is expected to do. > THEN P2P could be economically > efficient for all involved, because it would only transfer on > noncongested links. BitTorrent automatically avoids congested links. If a peer is indicating congestion (as determined by TCP throughput dropping), that peer will be dropped as a reciprocating peer and another peer will replace it. The congested peer will only be unchoked every few minutes for 30 seconds at a time. > But if there IS congestion (and current P2P will happily cause > congestion) then it has significant cost because it crowds out other > flows. BitTorrent no more causes congestion than anything else. > Bittorrent, with its many concurrent TCP streams, is particularly bad. > If you as a client says "BitTorrent gets 100 kbps", it WILL takes 100 > kbps pretty much no matter how much congestion there is and WHERE the > congestion is (local link, provider uplink, whatever), at least until > the point where the only thing significant you are fighting with is > the other users of BitTorrent. This is absolutely, positively untrue. 1. BitTorrent does have many TCP streams, but it is not "particularly bad" -- in fact, it's quite the same as any other application that transports over multiple sockets (e.g. a web browser). Regardless of the number of connected peers in a BitTorrent swarm, you will only be actively sending on 3 or 4 of those. The rest of them are idle waiting their turn and are using nearly 0 bandwidth. 2. If you as a client says BitTorrent gets 100 kbps, but your service only has 50 kbps, then I promise you (or challenge you to prove me wrong): there is no BitTorrent setting or feature or technology that will, as you say, "take 100 kbps pretty much no matter what." BitTorrent talks "TCP," just like your other TCP applications. There is nothing it can do to take the advantages you claim. 3. BitTorrent cannot leave you in a state "where the only thing significant you are fighting with is the other users of BitTorrent." At any one snapshot in time, at the moment when a transit router drops a packet, there will likely be 3-4 simultaneous BitTorrent flows (which are full-sized packets). There may also be other non-file-sharing user traffic, but these packets are smaller and have idle intervals between them. When congestion happens on a TCP link, the most common response is a random dropped packet. Because of physics, it's more likely that a P2P packet is nuked by congestion, which causes TCP to assume congestion and slow that flow. When congestion happens, the small and interspersed packet flows are the least likely to be affected. Therefore, the streams cut-back the most are those having the largest-continuous packets. The least affected streams are the ones with the smallest-infrequent packets. > This is also why WoW updates are generally considered "glacially slow" > compared to other torrents, dispite popularity. Blizzard's transfers occur when gaming is going on over the same links and on the local machine. During IO-intensive gaming activity, a player doesn't want a lot of BitTorrent network and hash-verification CPU overhead. MOST LIKELY, Blizzard has taken steps to ensure that the game threads have a higher CPU priority than the updater threads. I don't know Blizzard's motivations. Do you? Even so, Blizzard can't control the speed of a BitTorrent swarm. No publisher or tracker can. It is completely determined by the peers and the network conditions. Any throttling going on is happening either by the sending or receiving peers (or their ISPs). Robb Topolski