User:The8472/P2PvsISPs

From AzureusWiki

ISPs argue that P2P is overtaxing their backbone infrastructure - which might be right - because P2P applications are dumb and don't keep traffic local - which is incorrect. It is incorrect because P2P applications try to maximize the transfer rate, due to asymmetric connections and standardized broadband plans it is normal that a local peer B will never be able to upload as fast to local peer A than a foreign peer, for example one in Sweden can do. Thus the swedish peer will be preferred when it is able to provide more bandwidth than a local peer.

most P2P developers would be happy to ease the load on ISPs (Azureus supported Joltid PeerCaching for quite a while just for that purpose, but it was not widely supported by ISPs), but only when it wouldn't degrade bandwidth performance for their applications. Since simple "just prefer local connections"-logic wouldn't provide that kind of equal performance it would be a rather one-sided deal. To retain the performance there are several possible strategies:

1. ISP-local multicast (preferably source specific multicast, aka SSM. but this requires IGMPv3 aware network components and application stacks) to multiply the bandwidth of one uploader for specific content on the ISP to multiple clients within the ISP's network. This way asymmetric network conditions can be compensated to a certain extent and ISP-local peers become more interesting for the clients.
2. shadow bandwidth for ISP-local connections. I.e. bandwidth that is physically available to the home but not available for general internet access. Some triple-play schemes already employ such shadow bandwidth to guarantee spare capacity for VoIP or VoD, this could be extended for ISP-local connections in general and allow P2P applications to gravitate towards local peers and use the additional bandwidth
3. A generic, protocol-independent, content-agnostic and lawyer-resistant content caching system that is actively supported by P2P applications, ISPs and might even perform inter-ISP-peering of those caches. This might seem complex, but deploying multicast/igmpv3 support or ensuring that many customers have spare capacity is not a simple feat either.
4. Symmetric internet connections to the home, statistically a bittorrent client should at least be able to download at the same speed as he is uploading which means if internet connections are symmetric there would be no disadvantage in using a ISP-local peer as opposed to a foreign peer. Although this does not provide direct incentive to use ISP-local peers it at least does not make local peers less attractive than others.
5. If a node's download bandwidth is saturated and more peers than necessary unchoke this node then it could prefer to download from local peers, this would require an interface from the ISP to query the closeness of a specific IP(-Range), e.g. via DNS or a similar UDP-based service (via anycast would be the most convenient option). This would only have an impact on torrents with a surplus of seeders or (again) with symmetric connections. Other closeness approaches usually don't work as the would lead to clustering or lower the performance for the user.

The general point here is that P2P developers cannot simply concede to the requirements if ISPs w/o significant changes on ISP's the infrastructure side, otherwise they'd be sacrificing (user-perspective) advantages of P2P networks.

ISPs also have to accept that there is a long tail when it comes to content. I.e. hundredthousands of torrents with only a few peers scattered throughout the world, it is not possible to keep connections local if the only peers are on the outside. Caching/localizing solutions only work for popular torrents on large ISPs where a seizable fraction of the swarm resides within the ISP's network. This means that smaller ISPs would have to cooperate with their peering/upstream partners to use above solutions efficiently.