[ NNSquad ] Re: Comments on NNSquad Purpose

[Phil Karn <karn@ka9q.net>]

Brett Glass wrote:

> It's not how BitTorrent works. With BitTorrent, you have to send at
> least as much as you receive, so the total bandwidth each client uses
> is at least doubled. BitTorrent is designed to offload bandwidth
> demand, and possibly speed up the transfer, by co-opting bandwidth
> from other ISPs bandwidth. It does not conserve bandwidth; in fact,
> it wastes it because there is no opportunity for caching as there is
> with HTTP.

I think you should take a closer look at how Bit Torrent really works. 
Read its design documents, experiment with it and observe it in action 
instead of leaping to conclusions based on misconceptions.

If you set up a Bit Torrent seed, i.e., a node with a full copy of a 
file to be shared, and other nodes want that file, they will establish 
ad-hoc connections to each other and to the seed. They tell each other 
which pieces of the file they have and begin exchanging those pieces 
among themselves until everyone has the whole file.

An important feature of the algorithm is that peers place priority on 
getting the "scarcest" pieces of a file, i.e., those pieces with the 
fewest total copies in the swarm. Obviously there has to be at least one 
copy of every piece somewhere in the swarm, i.e., at the seed, or the 
transfer cannot succeed.

Whenever the seed sends a piece, at least two copies of it then exist in 
the swarm. It has become less scarce than the pieces the seed has yet to 
send to anyone, so the peers become much more likely to ask the seed for 
 pieces it has yet to send to anyone.

The effect is that the seed tends to send only one copy of each piece 
and the peers tend to share it among themselves instead of each asking 
the seed for their own copies. This makes much better use of the seed's 
limited upstream bandwidth.

Isn't this better for the seed's ISP than to ban Bit Torrent and force 
him to send a full copy to each and every recipient?

It's certainly possible for Bit Torrent seeds to send out multiple 
copies. A new peer might arrive, grab a complete copy, and then 
disappear before it has repaid its debt by passing on a full copy to 
someone else. The user might do this himself, or his misguided ISP might 
be interfering with the protocol. Either way, the effect is to shift the 
burden back to the original seeder and to any additional seeders.

Bit Torrent is actually quite cacheable. The ISPs merely set up Bit 
Torrent nodes of their own. Because they will have a fast outbound 
capability, peers will prefer to receive from them than from peers or 
seeds on user access links. If each ISP sets up a Bit Torrent node of 
its own, this will have the further beneficial effect of minimizing the 
traffic between those ISPs.

I'm sure that the Bit Torrent folks would be quite happy to work with 
the ISPs to build a special purpose Bit Torrent package optimized for 
caching purposes, e.g., by automatically participating in every torrent 
it sees. It has also been suggested that the Bit Torrent folks would be 
willing to work with the ISPs on peer selection algorithms that minimize 
their costs. This will require information from the ISPs and, of course, 
a cooperative rather than an adversary attitude.

Another way that the ISPs could make Bit Torrent more efficient is to 
(finally) implement IP multicasting. Without it, a sort of "packet 
conservation law" exists; for someone to receive a data packet, someone 
else has to send it. With IP multicasting, one data packet sent up a 
slow DSL or cable access link could be duplicated and sent to multiple 
receivers in such a way that usage of ISP resources is minimized.

Without multicasting or other assistance from the ISPs, users have no 
choice but to transmit every data packet themselves over their own slow 
uplinks. The ISPs have no one to blame but themselves for this 
unfortunate situation.

> Very few people would send out baby pictures via BitTorrent. By far,
> the absolutely overwhelming majority of BitTorrent traffic is pirated
> music, video, movies, and software.

That may be true, but it is still not 100%. 100% of my own Bit Torrent 
traffic is entirely legal, and I strongly resent the implication that I 
"must" be engaging in piracy simply because of the protocol I choose to 
move my material.

> I'm a service provider who is trying to make sure my customers get
> good service. My customers want me to prioritize real time traffic
> and de-prioritize non-interactive traffic such as file downloads.
> What's more, they don't want my upstream pipes to be congested by
> bandwidth hogs.

Fine. I'd like to help you, because I'd like to have good service too. I 
think the same is probably true for most of your customers. This is best 
accomplished with a cooperative relationship between the users and the 
ISPs, not an adversary one. I've already given several examples of how 
this cooperation could substantially reduce the ISP resources that file 
sharing with Bit Torrent would consume.

> Actually, some of our pipes ARE smaller upstream than downstream.
> (These are the ones that feed our Web cache.) However, as I've
> already mentioned, BitTorrent at least doubles the load, because it
> requires you to transmit as much as you receive. And you can cache
> FTP. You can't cache BitTorrent.

See above.

> > And are you aware of the safe harbor provisions of the DMCA?
>
> Frankly, I don't care if I can manage to get off the hook. I don't
> have deep pockets. If I'm sued, I'm already screwed.

My advice, then, is to stay out of the ISP business. That is the only 
way you can be sure of not being sued.

> No. Because you still will be attempting to hog and monopolize
> bandwidth. That's still abusive behavior.

If you don't want me to "hog" and "monopolize" your bandwidth, then I 
suggest that you build your own personal dedicated network and not sell 
it to anyone. I'm reminded of the South Park episode in which Eric 
Cartman bought his own personal amusement park.

When you go into the network service business, your customers have the 
right to expect to use it. That's why they pay you. There certainly 
should be a good faith give-and-take to maximize the value of your 
network to your customers while minimizing your costs. Your customers 
should be aware that most of the resources they use are shared with each 
other, and that their behavior patterns may affect the performance of 
the network as seen by the other users. And it is perfectly reasonable 
for you to discard excess traffic from some users when it is necessary 
to give a minimum grade of service to other users.

But it is NOT reasonable for you to make, by fiat, value judgments about 
the relative importance of your customers' traffic based on their 
selection of protocols, or unsupported assumptions about the legality or 
illegality of their transactions. That is, quite frankly, outside your 
job description.

You *should* give your customers the hooks they need to mark their 
traffic according to the importance that *they* (not you) place on it, 
and you should use these hooks as advice when deciding what traffic to 
discard when it is necessary to maintain a minimum grade of service to 
other users.

In sum, I simply cannot understand how such a hostile, adversary 
situation has arisen given that there are many workable technical 
measures that can alleviate the situation to everyone's benefit. I am 
hoping that education and discussion can lead to a productive outcome.

--Phil