Re: [p2pi] [tana] [tsv-area] TANA proposed charter

On Oct 22, 2008, at 1:49 AM, Rolf Winter wrote:
>>
>> Besides, there are ISPs that are worried about the effect
>> that P2P have on other applications when the link is
>> saturated, but otherwise they do not care. P2P would be
>> treated like best effort in non-saturated situations (a more
>> ECN type approach).
>
> That is exactly the point. P2P should not "harm" inelastic traffic.  
> In order to do that, queues should not build up as a consequence of  
> the P2P traffic. The charter according to my interpretation says  
> that the most suitable of the set of available means should be used  
> or any combination of it that makes sense.

There are actually at least two sources of harm that BitTorrent and  
related bulk-data P2P protocols can cause:

A)  Self harm on access-link buffers:  Simply because the protocol  
will very easily saturate uplinks for residences, and devices ON the  
uplinks (NAT boxes, etc) are often criminally overbuffered.  This is  
not really affected by the multiple-TCP flow nature of the protocols  
in question, as a single TCP flow will happily grab the full buffer as  
well, but P2P protocols tend to be the heaviest user of the uplink.

B)  Congestion on shared-access uplinks:  DOCSIS is explicitly a  
shared-bandwidth media.  Thus a few users of a P2P protocol (many- 
flow, full-data-rate) can acquire a large amount of the shared channel.

Part of the problem:  A and B may require different strategies and  
solutions:

A is the one which the P2P developers are most interested in, because  
that directly harms their customers.  If you provide a solution to A,  
it will be deployed, and quickly.

B is the source of conflicts between the ISP and P2P, why ISPs have  
tried managing the upload rate, and why some ISPs, notably Comcast,  
are shifting to a network-enforced fairness approach.

Dealing with B is what I personally consider essential for a scavenger  
class protocol, and the more interesting problem, but I think it may  
be trickier, because you can solve A but not B with delay-based hacks.

But solving B also has another problem:  If P2P program Gamma and P2P  
program Delta are sharing the same uplink, and Gamma implements a  
scavenger protocol, its going to get squeezed out if congestion occurs  
on the uplink and, if any reciprocity is involved, the user's download  
is also going to suffer.

So there may be reasons for P2P developers to use techniques which  
solve A AND B, but there doesn't seem to be so clear an incentive for  
such solutions over solutions for A alone.

_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi