[p2pi] Stupid question, why not TCP Vegas?

[Nicholas Weaver <nweaver at ICSI.Berkeley.EDU>]

Pardon me for a stupid question:

TCP Vegas is already well understood as being an effective delay-based  
congestion control protocol with only one problem: TCP Reno  
outcompetes it in the standard tuning, because Vegas backs off earlier.

Yet these are exactly the features that bulk-data P2P would want for  
scavenger flows:  It is more sensitive than TCP Reno, and it doesn't  
fill up buffers in overbuffered-equipment (no +1 second ping times).


It is supported in the Linux kernel, and if there is compelling reason  
it could either get included into the Windows kernel or there is  
always the "alternate tcp.sys" hack that was first popularized when  
Windows added the Williamson-like outbound throttling.


So the question is, why aren't the P2P developers pushing TCP Vegas,  
and using it whenever possible?


If all TCP flows related to a program can be set to use delay-based  
congestion control, this should prevent the buffer occupancy problems  
they experience on the outbound link and, because it is less  
aggressive than standard TCP Reno (and variants), the default outbound  
transfer rate can be uncapped (or at least relaxed) without causing  
problems, and if the other side is using Vegas as well, the inbound  
rate can also be uncapped.

It seems that what would be needed is

1:  Windows support for TCP Vegas, either as a Microsoft updates or  
the alternate tcp.sys.

2:  A way of per-connection or per-app specifying the desired  
congestion control, so that a P2P program can specify "TCP Vegas".   
(Linux is a global /proc option rather than a per-app option IIRC).


Thoughts?  Comments?


(If this would work, it also suggests that I was wrong about "no  
incentive to be a scavenger":  I forgot that you can actually be  
better at using bandwidth (eg, TCP Vegas, because it doesn't sawtooth  
between full bandwidth and 1/2 bandwidth, especially when its the only  
flow) while being friendlier than vanilla TCP)

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