Re: [p2pi] One thought on "leech killing"

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> wrote:
> 
> 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.

   Certainly there are any number of lawyers who would be happy to argue
that for $250 per hour. I don't volunteer to pay them...

   I take issue with your measure of "benefit" to the customer. In general,
the customer is considered a better judge of perceived benefit than the
supplier. Or did Comcast offer this as a opt-in service to customers? If
so, it would be interesting to know what percentage opted in.

   There are indeed _some_ customers driven by pure greed to take whatever
they can and give nothing back. IMHO, those folks will leach off their
neighbor's wireless instead of paying Comcast: thus I believe it reasonable
to conclude that the _paying_ customers are willing to give something back.

   Recall that upstream and downstream bandwidths are separate issues:
the technology imposes no significant cost on one from using the other.

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

   (I suppose I should thank you for recognizing that some customers
intentionally act to give something back.)

   This particular "benefit" escapes me. If the computer is unattended,
I see no possibility of a "cost" to be avoided; if the user is typing
or clicking to some other application, the "cost" is too small to measure.

> 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.

   There are shades of "deliberately"...

   They were, of course, provided notice of sorts -- the "no servers"
clause in their service agreement. And I don't mean to fault Comcast
for putting in such a clause. Nor is it necessarily Comcast's
responsibility to provide the workaround.

   If Comcast is to be faulted here, it must be for "forging" the RSTs.

> 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).

   Interestingly, this "classic conflict" was never talked about when
BitTorrent was operating between user who all had symmetric upstream
and downstream bit-rates. Indeed, I consider it wrong to cast the
conflict that way for asymmetric service (cable and most telco DSL).

   Instead, I would cast the conflict as a failure of P2P programmers
to recognize upstream congestion issues and ensure that they don't
overload the upstream.

> 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?

   Clearly, "must ignore" would be stupid.

   To say it more nicely, any ISP whose customers experience excessive
upstream congestion "must" do something to alleviate it. Ideally, this
would include any necessary upgrades to increase upstream bandwidth.
In the short term, there are a number of well-established principles
for bandwidth limiting. (Google for "dummynet" if you don't know them.)

> 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?

   I don't understand the question.

--
John Leslie <john@jlc.net> 
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi