<div dir="ltr"><div class="gmail_quote">2010/3/6 Shachar Shemesh <span dir="ltr"><<a href="mailto:shachar@shemesh.biz">shachar@shemesh.biz</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir="ltr" bgcolor="#ffffff" text="#000000"><div class="im">
Ohad Levy wrote:
<blockquote type="cite">You would need to know what to sniff, e.g. if tcp dynamic
window scaling is enabled.
<div><br>
</div>
<div>I'll be interested in what you consider dirty tricks? <br>
AFAIK increasing the tcp window size (read: send more data for every
ack) is not considered dirty trick at all, and is very efficient with
good connections (low packet drop) and high latency.</div>
<div><br>
</div>
<div>Ohad<br>
</div>
</blockquote></div>
The legal tricks are, mainly, two.<br></div></blockquote></div><br>There are several things to note here, you should use a congestion control algorithm that is better optimized for the long-fast-pipe case, the default of the linux kernel is bic which is better than the reno/newreno case. But you can also try cubic and htcp. Be sure to increase the default and maximum send/receive windows to allow the window scale to be set high enough to make use of the bandwidth. You should also ensure that you are running a sufficiently new kernel as very old kernels (circa 2.6.16) had various bugs in bic and/or sack processing that prevented them really hitting it to the max.<br>
<br>Another approach is to use vegas/westwood and such congestion control that do not work based on packet loss but rather go for delay, but they are problematic in the normal Internet since there are losses and they interact badly with such algorithms severely limiting their usefulness.<br>
<br>Baruch<br></div>