Linux TCP stack repeatedly sends "TCP window update" without acknowledging any data

Question

My company is developing its own TCP stack for low-latency purposes and one of the tests involves running 128 instances of ncat on Linux 4.11 to listen to ports 55000 through 55127 and sending data in 128 threads on another computer through our own TCP stack to each of the 128 ncat servers.

There is, apparently, a part of the TCP protocol that we didn't implement. As shown in the pcap below, the ncat server immediately sends over a "TCP window update"; this segment has "1" for both its relative sequence and ack numbers.

Our software doesn't seem to handle this condition correctly, because it goes on to send ever more data and eventually chokes, thinking that it hit the congestion window limit having sent all these "un-acked" segments.

What are these strange and wonderful (seq=1 ack=1) packets?? Where in the RFC are they mentioned, and what's the correct behaviour in this case??

part of the PCAP:

Answer 1

Ok, after some investigation I learnt that

1) data in syn handshake is legal, and

2) the weird segments are duplicate acks and receive window updates rolled into one: the first chunk of 256 bytes of payload was in fact dropped somewhere in the Linux kernel between receiving the frame and delivering it further up the stack.

Because of the window update, this does not trigger fast retransmit in our software, and the expected behaviour (since we don't implement SACK) is timeout retransmit. Alas, I commented out the segment retransmission function while debugging it and forgot to revert the changes.

I hope these findings are of some use to other people who stumble upon similar issues.