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

From: Nicholas Weaver <[email-masked]>
Date: Mon, 2 Jun 2008 08:31:30 -0700

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
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: John Leslie <[email-masked]>
Date: Mon, 2 Jun 2008 14:52:20 -0400

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

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

> this penalizes the customer.  And they should have been provided  

   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.

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

> the rest of the aggregate that have the effect of penalizing ALL their  

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

> "reciprical" and "greedy" behaviors?

   I don't understand the question.

--
John Leslie <[email-masked]> 
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: "Robb Topolski" <[email-masked]>
Date: Mon, 2 Jun 2008 13:16:20 -0700

To John:

I liked your post very much and agreed with much of it.

> to recognize upstream congestion issues and ensure that they don't

With respect, the P2P programmers that I've met are very congestion
sensitive.  There is no benefit to cramming data down a congested path like
HTTP or FTP does.  BitTorrent is designed to avoid congestion!  If a link
begins to slow or stops due to congestion, it stops that one and begins to
upload on another one.  And the number of slots it will upload on start at 3
or 4 per transfer (given most U.S.A. uplink allocations, but this number is
growing as FIOS competition drives our upload speeds higher and I'm a little
concerned a little about that).

> the rest of the aggregate that have the effect of penalizing ALL their

I maintain that prolonged periods of congestion mean that you've already
failed to manage the network.  Trying to figure out which bucket of water to
throw out before another is ignoring the fact that the boat is sinking.

> "reciprical" and "greedy" behaviors?

Indeed.  But why should Internet users be forced to do anything?  The beauty
of the Internet is its wonderful cacophony of interactive uses.  I'm not
"tuning in" to the limited selection of channels in my area.  It's not
delivered one-way only.  Your question contains the answer -- forcing
someone to use the Internet in a certain way is usually incompatible with a
free and open Internet.

Banning something on the net seems wrong on its face.  I remember when spam
started to really grow as a problem, many of us were debating whether or not
to care.  Most of the ads then were legitimate, but they were simply widely
broadcast and nearly always unwanted.  At first, banning spam outright
seemed wrong unless there was another reason (forgery, illegality).  We
spent a lot of time on the question of under what conditions to block it.
It did help that email was blocked at the service level and not at the
protocol level -- my server, my rules applied.  Network access and transit
operators do not have that privilege.

Robb Topolski

-- 
Robb Topolski ([email-masked])
Hillsboro, Oregon USA
http://www.funchords.com/
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 2 Jun 2008 14:42:43 -0700

On Jun 2, 2008, at 1:16 PM, Robb Topolski wrote:
> I maintain that prolonged periods of congestion mean that you've  
> already failed to manage the network.  Trying to figure out which  
> bucket of water to throw out before another is ignoring the fact  
> that the boat is sinking.
>

Or you throw off the suitcases full of lead...

Your argument works when the congestion's cause is a large fraction of  
the user base.  But when it is a small fraction of the user base and  
you maintain flat-rate pricing, it makes far more economic sense to  
employ traffic management techniques to prevent the heavy users from  
impacting everyone else.

For example, Comcast's problem is very clear: DOCSIS, even DOCSIS 3,  
is a shared medium across a large group of users.  So unless they are  
willing to pull fiber to the home [1], there is no miracle bandwidth- 
fairy that can come and solve their congestion problem: they HAVE to  
allocate that bandwidth between users in a way which maximizes the  
benefit for the maximum percentage of customers.

And DOCSIS 3 is only 4x the bandwidth per channel of DOCSIS 2: the  
Japanese have shown that even 100 Mbps fiber-to-the-home can get  
congested with P2P traffic.

[1] The only way fiber to the home happens is either government  
subsidies or when a Telco wants to break into the cable-TV business by  
pulling fiber and then getting a statewide license (Verizon).