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

On Oct 21, 2008, at 10:41 AM, Nicholas Weaver wrote:
>  do an immediate backoff/slow ramp-back when you see RTTs increasing  
> to MULTIPLE peers.

Very true, and a special case of more general, and applicable to TCP,  
etc.:

Any delay-based congestion control can be modified to key off the min  
delay to multiple peers, effectively ignoring far-away congestion.
Any loss-based congestion control can be modified to key off the min  
loss to multiple peers, effectively ignoring far-away congestion.

Any congestion control based on a numeric measure of congestion can be  
modified to key off the min measure of congestion to multiple peers,  
effectively ignoring far-away congestion.

("Far-away" = beyond the point of divergence of paths of the different  
flows.)

In practice, I don't believe there are interesting benefits for doing  
so for P2P apps.  For swarms that have a fighting chance, even the  
nicest behaviors yield excellent results.  The main reason to get poor  
results is very small swarm size.

Regardless -- congestion control on the Internet is done by  
endpoints.  In the end-to-end framework, we can't do very much about  
noncooperative endpoints, but, luckily for us, there are relatively  
few of those.

Making the congestion control mechanisms of cooperative endpoints more  
suitable for their goals can yield great benefits.  Most P2P apps want  
to be cooperative as far as congestion control goes.  In fact, you  
don't often see non-P2P apps that come with the expectation that users  
will manually set the right rate limits on them and prominently  
accessible UI for doing so.  (The point of these rate limits is, of  
course, to send at a rate lower than would normally be produced by the  
nicest of congestion control mechanisms.)

Thank you,
--
Stanislav Shalunov

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