[Sake Blok <sake@xxxxxxxxxx>]

On Thu, Feb 08, 2007 at 09:03:58AM -0500, Chad Handrich wrote:
> I have a network client application that runs fine while I am debugging (no TCP errors),
> but when I run the release version, it runs incredibly slow.  It runs as a series of
> transactions, where each transaction is a separate connection to the server.  Wireshark
> analysis has determined that about 50% of all transactions involve the series:
> 
> TCP Previous Segment Lost
> TCP Dup ACK
> RST

I can imagine 50% of the sessions having this sequence after the 
analysis that follows at the packet-list :)


> The RST consumes 3 seconds per transaction, which is a Big Deal.  So to prevent it, I must
> prevent the initial "TCP Previous Segment Lost" (which seems, on the surface, to merely be
> a time-out on a particular segment).

It is not the RST that consumes 3 seconds, it's the way TCP retries to
setup a connection when it initially fails to do so.


> In the following clip, the SYN packet suffers from the "TCP Previous Segment Lost" condition.
> 0.000640 seconds seems like too short of a time to declare this condition, as many previous
> successful transactions took much longer to be successfully SYN-ACK'ed.

True! But it is a different problem, see below...

 
> Can somebody explain "TCP Previous Segment Lost" in this context to help me troubleshoot my
> problem?
> 
> Any help would be appreciated.

I will tell you what I see in the packets :)


> Here is a clip of a problem transaction:
> 
> 
> No. Time        Source                Destination           Protocol Info
> 834 *REF*       89.194.102.223        89.89.200.210         TCP      1137 > 1152 [SYN] Seq=0 Len=0 MSS=1460

This is the initial TCP-SYN which should set up the connection. The seq=0
is due to your wireshark setting to use reletive sequence numbers.

> 835 0.000640    89.194.102.223        89.89.200.210         TCP      [TCP Previous segment lost] 1137 > 1152 [SYN] Seq=21767 Len=0 MSS=1460

Somehow the client tries a second time to establish a connection using the
same src-port, but now with a different sequence-number. Since wireshark
kept track of the sequence-numbers for this conversation, it thinks there
was data missing in between the two packets, as the sequence number is now
21767 higher than that in the frame 834. Hence the "[TCP Prev ious
segment lost]" message.

> 836 0.001345    89.89.200.210         89.194.102.223        TCP      1152 > 1137 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460

This is the SYN/ACK to the SYN in frame 834 (because the ack=1, the ack of 
a SYN/ACK is always 1 higher than the seq of the SYN).

> 837 0.001360    89.194.102.223        89.89.200.210         TCP      1137 > 1152 [RST] Seq=1 Len=0

Since your client sent another SYN with a higher sequence number (frame 835)
it thinks this SYN/ACK is not valid (it's valid to frame 834, not to 835),
the client drops the connection.

> 838 0.001371    89.89.200.210         89.194.102.223        TCP      [TCP Dup ACK 836#1] 1152 > 1137 [ACK] Seq=1 Ack=1 Win=5840 Len=0

This ACK I can't place

> 839 0.001379    89.194.102.223        89.89.200.210         TCP      1137 > 1152 [RST] Seq=1 Len=0

This is a RST on the ack in frame 838, cause it is out of sequence

> 840 2.993571    89.194.102.223        89.89.200.210         TCP      1137 > 1152 [SYN] Seq=21767 Len=0 MSS=1460

This is a retransmission of the SYN in frame 835

> 841 2.994880    89.89.200.210         89.194.102.223        TCP      [TCP Previous segment lost] 1152 > 1137 [SYN, ACK] Seq=2993603 Ack=21768 Win=5840 Len=0 MSS=1460
> 842 2.994909    89.194.102.223        89.89.200.210         TCP      1137 > 1152 [ACK] Seq=21768 Ack=2993604 Win=17520 Len=0
> 843 2.995387    89.194.102.223        89.89.200.210         TCP      1137 > 1152 [PSH, ACK] Seq=21768 Ack=2993604 Win=17520 Len=9
> 844 2.996103    89.89.200.210         89.194.102.223        TCP      1152 > 1137 [ACK] Seq=2993604 Ack=21777 Win=5840 Len=0
> 845 3.084802    89.89.200.210         89.194.102.223        TCP      1152 > 1137 [PSH, ACK] Seq=2993604 Ack=21777 Win=5840 Len=22
> 846 3.084829    89.89.200.210         89.194.102.223        TCP      1152 > 1137 [FIN, ACK] Seq=2993626 Ack=21777 Win=5840 Len=0
> 847 3.084853    89.194.102.223        89.89.200.210         TCP      1137 > 1152 [ACK] Seq=21777 Ack=2993627 Win=17498 Len=0
> 848 3.085844    89.194.102.223        89.89.200.210         TCP      1137 > 1152 [FIN, ACK] Seq=21777 Ack=2993627 Win=17498 Len=0
> 849 3.086408    89.89.200.210         89.194.102.223        TCP      1152 > 1137 [ACK] Seq=2993627 Ack=21778 Win=5840 Len=0

And this is the normal flow of packets...

The big question is where does the second SYN packet come from...

Hope this helps, Cheers,


Sake