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

On Oct 21, 2008, at 10:06 AM, Stanislav Shalunov wrote:
>> Yet why would a bulk-data content provider want to USE it?
>
> This is a great question and it deserves a more detailed answer than  
> this, but let me try, briefly, to provide one reason to use it:
>
> Because the user wants to use the Internet while P2P app is doing  
> whatever it is doing.  Or the user will uninstall the app.
>
> The content provider serves at the leisure of the user.  The user is  
> willing to share uplink capacity as long as the sharing is largely  
> invisible.  The user will be upset by uploads that affect the user's  
> ability to use the network for interactive applications and web  
> browsing.
>
> (There are other scenarios, particularly with shared congestion and  
> traffic management, that generally push the content provider to be  
> nicer, so the above is just one example.)

However, the "Internet Not Working" effect is a subpiece of the  
overall problem:  It is buffer occupancy on end-user buffers where the  
buffers are on the order of 1+ RTT (often 1+ Second!).   Otherwise,  
the incentives are to be as UN-friendly as possible, as the  
externalities of congestion, EXCEPT at the access-link device, are  
applied to other users.

Thus the P2P application provider can use existing RTT-based  
congestion control techniques to look for a greater than .25 RTT  
increase in delay, and respond to it by shrinking window sizes until  
the RTT drops and at-that-point, call it good.

In fact, simply feed this into bandwidth estimation:  Do an initial  
uncongested bandwidth estimation on startup (packet-pair measurement)  
to other peers (eliminates the "select a bandwidth" checkbox, bonus!),  
attempt to allocate to the whole pipe-5% with your TCP flows, and do  
an immediate backoff/slow ramp-back when you see RTTs increasing to  
MULTIPLE peers.

Although a new class of congestion control that would do a true end-to- 
end job would be a better solution, the partial solution is complete  
from the P2P application provider's viewpoint: it fixes the "We break  
the net for everything else" effect on the user, while still keeping  
the very agressive (many-flow TCP) properties of P2P for the rest of  
the network.

Or at least until you bribe the NAT box vendors to implement some  
active queue management.

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