<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">

</head>

<body dir="ltr" bgcolor="#ffffff" text="#000000">

Ohad Levy wrote:

<blockquote

 cite="mid:9ab1d3a91003052007v52a29d7vecbccff079bd0dba@mail.gmail.com"

 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>

The legal tricks are, mainly, two.<br>

<br>

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.<br>

<br>

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.<br>

<br>

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.<br>

<br>

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.<br>

<br>

Shachar<br>

<br>

<pre class="moz-signature" cols="72">-- 

Shachar Shemesh

Lingnu Open Source Consulting Ltd.

<a class="moz-txt-link-freetext" href="http://www.lingnu.com">http://www.lingnu.com</a>

</pre>

</body>

</html>