[p2pi] One thought on "leech killing"

[Nicholas Weaver <nweaver at ICSI.Berkeley.EDU>]

Comcast's traffic management of bulk-data P2P was reportedly just  
"leech/seed" killing.  And this appears to be correct based on our  
study of injected RSTs (in submission) [1]

The interesting question is as follows:

1: For leech killing, it can be strongly argued that this benefits the  
customer while hurting BitTorrent.  You would do better if your client  
only talks to people who have blocks you don't have.

2: For seed killing, if the user was just a participant and did not  
deliberately leave the client open, this benefits the customer.

3: For seed killing, if the user is deliberately acting as a seed,  
this penalizes the customer.  And they should have been provided  
notice and a workaround.

But the first two cases are part of the classic conflict in  
BitTorrent:  the rest of the swarm benefits from allowing leeching and  
seeding, but the user doesn't (as well as any other flows sharing a  
bottleneck with the user).



This brings up two interesting questions:

a) Is it ok for ISP traffic management be limited to solely  
benefitting their customers or must it ignore behavior that benefits  
the rest of the aggregate that have the effect of penalizing ALL their  
customers?

b)  How do bulk-data P2P systems evolve if participants are FORCED to  
eliminate "altruistic" behavior (allowing leeches), but limited to  
"reciprical" and "greedy" behaviors?





[1] The comcast RST injector, on P2P traffic showed that it was almost  
completely killing what look by simple traffic analysis to be leeching/ 
seeds:  it ONLY killed flows where there were a lot more bytes (10  
kB-1MB) from the comcast peer, and only a few (less than 1 kB) from  
the ICSI peer.  This looks to be like "I'm only sending the first  
block, not asking for a block".

The only exception are 7% of the flows where only a couple hundred  
bytes are exchanged, although the Sandvine CTO reports that their  
system at least supports recognizing "this peer says it has ALL the  
blocks, so it must be seeding".  I hope to verify this by examining  
the archived packet traces.
_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi