Re: [lwip-users] Duplicated ACK and retransmitted packets - some news

[Kieran Mansley]

On Tue, 2010-02-09 at 20:08 +0100, Lou Cypher wrote:
> I made some more tests, and found a couple of different things going on, one 
> on
> my side (data buffering), the other /apparently/ in lwIP.
> 
> Take as a reference the extract of Wireshark's trace in the OP, at least with
> the packets
>  28 PC -> lwIP (FTP command reply)
>  29 PC -> lwIP (data)
>  30 PC -> lwIP (data) (**lost in buffering**)
>  31 lwIP -> PC (ACK)
>  32 PC -> lwIP (data)
>  33 lwIP -> PC (ACK)  (duplicated)
>  34 lwIP -> PC (ACK to command reply)
>  35 PC -> lwIP (data) (retransmission)
> 
> 1. Retransmission
> The TCP retransmission packets are there because of a data buffering error. 
> The
> MAC I'm using has been instantiated in an FPGA with just *one* packet buffer:
> when a second packet arrives, and I'm still handling the first one, the new 
> one
> gets lost.
> In that trace: packet 29 (data, server -> client) makes it through, but packet
> 30 is not seen by lwIP.
> I talked to the FPGA guy, and probably I could get double buffering for the 
> MAC,
> so that things become faster.
> 
> In the meanwhile (having TCP_MSS = 1460) I reduced the TCP_WND, and made it
> exactly the size of MAC rx buffer (2048 bytes), such that only a single packet
> (1460 + stuff) can be sent at once... Retransmissions have mostly disappeared 
> --
> small packets are still sent /sometimes/, when their size is <= 2048 - (1460 +
> stuff).
> Is my assumption correct?

I think this setup is fundamentally broken.  You can't do TCP with one
or even two buffers at the MAC layer and not expect considerable loss.
TCP's algorithms only really work well when TCP_WND >> TCP_MSS.  A
sender does not have to provide MSS-sized segments; it could fill the
window by sending many smaller ones.  You device could receive frames
from other sources or other connections, and so exhaust your buffers
just before you get a packet that you really wanted.  All of these mean
you need many more MAC buffers.

> 2. Duplicated ACK
> They do exist, yes. It can be seen in trace packets 31 and 33.
> Packet 31 is a legitimate ACK, has IP packet ID = 105, and ACKs TCP packet 29,
> with acknowledgement number 1461.
> Packet 33 has IP packet ID = 106, and for TCP it ACKs *again* 1461, so this 
> is a
> duplicated ACK. Note how it is also a valid packet packet, with valid 
> checksum,
> so it can only have been generated by lwIP.
> Looks like it should have ACKed packet 32.
> Again: does it make sense?

Sounds OK to me from your description and looking at the capture.
Packet 30 is lost and lwIP keeps ACKing 29 (i.e. seq 1461) until the PC
retransmits the data from 30 in packet 35.  lwIP then ACKs all the
received packets (30/35 + 32) in one go - this is packet 36.

Kieran