Speed problem - smbclient doesn't send duplicate ACKs in case of pacekt loss

[Henrik Nordstrom]

On Sun, 2 Jan 2005, Heinz Knocke wrote:

> My general question is why it happens and what can I do about it? Is
> it a samba side problem or OS' ? I don't expect to be the latter,
> because netperf TCP stream gives as much as 720 Mbps.
> One thing that specially makes me wonder, is that theoretically client
> doesnt need to send duplicate ACK, because the missing segment is the
> last in the burst sent (see packet dump extract below). So it may not
> know if it's just missing or never sent. What should the TCP do then,
> what may I tune?

The client side TCP should not send a duplicate ACK in this specific case.

The source to the difference here is timing. netperf is a server 
continously trying to send data to the receiver, while Samba is using a 
record based protocol where the client pulls data from the server by 
sending requests. If a segment is lost in a netperf stream additional 
segments follows shortly and the receiver will send duplicate acks to 
indicate packet loss, while if the last packet in a Samba message record 
is lost then no additional data will follow until server side TCP 
retransmit timeout. At least according to my fairly non-existing 
understanding of the SMB protocol (no heavy use of pipelining of requests, 
limited size request records most of the time).

If the lost segment is not the last packet in a message record then client 
side driven TCP recovery should kick in quickly, as seen in your netperf 
session.

Note: In the above context client == data recipient, server == data 
sender, but the problem applies in any direction of the TCP stream.

Regards
Henrik