RE: [lwip-users] FTP-DATA exchange: advice needed

[Kieran Mansley]

On Tue, 2005-02-22 at 09:30 -0800, Tom C. Barker wrote:
> Attached is the truncated dump: only familiar with
> dumping files from the gui in Windows, I looked 
> around and found editcap.exe to convert the dump
> to the form you had requested.

Great, thanks.

First off, you seem to have a very slow node (216.101.63.81)!  It takes
it well over a second to respond to the SYN-ACK (packet 2) with an ACK
(packet 3).  This suggests either it's seriously underpowered, or
there's something wrong: it could be that it only goes at all because of
a timer (like the slow timer) firing.  Check that you are servicing the
stack correctly.

Secondly, there is quite a lot of loss for such an uncongested link.
There are certainly a number of retransmissions anyway, although with
many of them they appear to be for data that was transmitted fine the
first time.  (Could be it went missing between where the trace was
captured and the other end though).  Some of the retranmissions can also
be attributed to the "81" node taking a very long time to ACK them.

Thirdly, the fact that the advertised window is getting smaller and
smaller all the time suggests another problem.  This indicates that the
application on the "81" node is even slower than the stack (which is
pretty incredible, given how slow the stack seems to be running!) and so
data are backing up waiting to be read.  This means the stack can't
advertise those buffers to the other side, and eventually the window
goes down to less than 1 segment (1450 < 1460 bytes).

When the window is less than 1 segment, the sender may wait for a while
in the expectation that it'll get another ACK soon with a larger window,
and so enable it to send a whole segment rather than a fragment.  This
is Nagle's algorithm.  The sender is probably doing this.  One odd thing
here is that Nagle says you should only delay sending if you already
have any unacknowledged data in flight (i.e. something that you've sent
that hasn't been acked).  This is not the case in this example, so I'm
guessing the sender is doing something like Nagle, but not conforming to
the spec.  Many stacks won't send any data to a stack advertising less
than 1 MSS of window at all just to try and be more efficient.

So, to summarise, I would find out:
(i) why your receiver is so slow
(ii) why the reading application isn't able to keep up (or why, if it
is, does the advertised window get smaller and smaller)
(iii) if you can't change either of those, how you can alter the
behaviour of the sender to not wait so long before sending to a node
that advertises a window < 1 MSS

Hope that helps,

Kieran