RST acknowledgment numbers

edit

I have been asked to diagnose an issue with a client that is complaining of dropped packets or delays along the network. I've come across some weird behavior and would like some clarification regarding the expect behavior for TCP RST. I have pasted the RAW Sequence and ACK numbers below (ACK is in BOLD). As seen from the four-tuple these are all from different tcp conversations. The Sequence numbers are difference, as one would expect, but the ACK number is the exact same within the entire capture period. These are also from different Source IP addresses. For further context, these RST's are coming after the Client and Server have both sent a [FIN, ACK] in both directions. After which, the [RST] comes into play and then the client sends a number of [TCP Retransmissions]. I personally have never come across this before. Typically I see 0 for the ACK number. My question is, If the RST Flag is the only FLAG set, is it normal behavior to have the same ACK number across multiple streams?

Sequence Number Next Sequence Number    Acknowledgment Number   Identification  Info
260418613   260418613   4294967196  0x034b (843)    443  >  50686 [RST] Seq=260418613 Win=0 Len=0
3644346981  3644346981  4294967196  0xc3ca (50122)  443  >  38598 [RST] Seq=3644346981 Win=0 Len=0
3944270739  3944270739  4294967196  0xd3dc (54236)  443  >  35794 [RST] Seq=3944270739 Win=0 Len=0
3824746242  3824746242  4294967196  0x529e (21150)  443  >  35798 [RST] Seq=3824746242 Win=0 Len=0
1892430094  1892430094  4294967196  0x4615 (17941)  443  >  35814 [RST] Seq=1892430094 Win=0 Len=0
1269827104  1269827104  4294967196  0x9d3e (40254)  443  >  50730 [RST] Seq=1269827104 Win=0 Len=0
8804867 8804867 4294967196  0xd821 (55329)  443  >  35834 [RST] Seq=8804867 Win=0 Len=0
1820382848  1820382848  4294967196  0x0201 (513)    443  >  50746 [RST] Seq=1820382848 Win=0 Len=0