Re: [lwip-users] TCP send queue and small windows

[Kieran Mansley]

On Mon, 2007-03-19 at 16:17 +0100, Per-Henrik Lundblom wrote:
> Have I understood this right? If yes, is the solution to implement 
> fragmentation for the unacked/unsent queue in tcp_output()?

So, both sides have data to retransmit in the unacked/unsent queue, but
they can't send it because the other side isn't advertising enough space
because all its space is used up by the unacked/unsent queue?

Changing the receive window length as you are doing is rather unusual,
and although not technically illegal it may result in you advertising
available space one minute, then reneging on that advert later by
advertising a smaller window.  It is normally assumed that once the
right window edge has been advertised, it won't be made smaller (in
sequence space) and that those buffers will continue to be available for
receive.  However, as I said, what you're doing is technically OK, just
unusual, and so not the cause of your problem.

The simple solution would be to set the size of the send queue to be
slightly smaller so that there was always at least one MSS of space
available for the receive window.  This might limit your performance
slightly (as you're putting a smaller limit on the send window) but
shouldn't affect it too much as we're only removing one MSS from it.

e.g Let's assume you have 16KB of memory for network buffers.  If you
set your max send queue len (in bytes) to be 12KB, there will always be
4KB of data for packets that aren't in the unacked/unsent queues, and
they should be available for use for receiving packets.

Being able to fragment a packet so that some of it could be sent
probably wouldn't help you a great deal, because if you are able to get
into this situation with less than 1 MSS of advertised space, you could
get into the same situation but with zero advertised space.  Then you
couldn't send any data no matter how much you fragmented the packets,
and so you'd be in the same hole.

Hope that helps,

Kieran