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

_______________________________________________
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Reply via email to