kernel optimization for long distance download??

[Shachar Shemesh]

Ohad Levy wrote:
> You would need to know what to sniff, e.g. if tcp dynamic window 
> scaling is enabled.
>
> I'll be interested in what you consider dirty tricks? 
> 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.
>
> Ohad
The legal tricks are, mainly, two.

One is "SACK", or "selective ACK", which allows marking TCP packets as 
received after a lost packet, thus preventing retransmission of the 
entire window after the lost packet.

Another one is "window scale", which allows a window of more than 64KB. 
This one is a problematic one, as the scale needs to be negotiated 
during the three way handshake, at which point the machine, typically, 
does not yet know it is on a high latency connection. The WS option is 
determined according to the buffers allocated to the TCP socket. I don't 
remember whether you control these using ioctl, fcntl or setsockopt, but 
these are controllable by user space. Either way, I doubt these are 
relevant here, as the buffers need to be set by the side that is 
receiving the data, which is, in the case of a standard server, the client.

The main illegal trick is called "predictive ACKing". It involves a 
proxy server that sends ACKs to packets it has not, yet, seen. Many 
people swear by that trick, but I, personally, doubt its effectiveness. 
What's worse, if a packet sent due to predictive ACK does get lost, the 
entire connection might get irrecoverably hung.

Another potential illegal trick is to recompile the server's TCP/IP 
stack to perform some function over the received window size, 
effectively forcing the effect of window scaling on the client. The main 
problem with this one is that, if not done right, it can totally screw 
with TCP's congestion control.

Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20100306/92b5f4c9/attachment.html>