This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Too many tcp retransmissions

0

Hi All,

We are seeing too many tcp retransmissions from the exchanges we have integrated with. Here is one of the issues we are seeing, and it causes timeouts. I am very new to this, so would like some insights about how to resolve such kind of issues. I can provide a bigger set of data if required.

Attached is the screenshot.

Thanks, Dhaval alt text

asked 06 Aug '14, 13:24

dhavalkotecha's gravatar image

dhavalkotecha
1●1●1●2
accept rate: 0%

edited 06 Aug '14, 13:27

We are seeing too many tcp retransmissions

there is only one retransmission in your example, which is perfectly normal for almost any network out there. So, based on the information you provided so far, it's impossible to answer your question.

Oh wait... What is your question?

(10 Aug '14, 08:27) Kurt Knochner ♦

One Answer:

1

Based on the screenshot I think the problem is the "client" not adding the tcp timestamp option in packet #4 as negotiated in the 3-way handshake.
Therefore the server discards this 4 byte segment and indicates the gap in packet #6 after having received a 1677 bytes out-of-order segment.
200 ms later the client terminates the connection by sending a FIN packet which generates the first dup-ack for seq 1.
Another 1.000 ms later the client's retransmission timer expires and seq# 1 is finally retransmitted (bypassing segmentation offload this time).

What can be done?

  • Fix the client (=Exchange?) to always add a tcp timestamp option to every segment once negotiated in the 3-way handshake
  • Disable the TCP Timestamp option in your Windows Server using netsh int tcp set global timestamps=disabled

It would help to add a capture file to cloudshark.org instead of just adding screenshots for detailed analysis of this kind of problems.

answered 11 Aug '14, 06:16

mrEEde's gravatar image

mrEEde
3.9k●15●22●70
accept rate: 20%

Hi mrEEde,i have a query as per my understanding a host that receives a TCP segment with a TCP timestamp must compare the current timestamp in the segment with what it considers the previous timestamp. If the timestamp is equal or greater than the previous one, it is acceptable. Otherwise, the segment should not be acknowledged. But as you said packet without timestamp so server is discarding it,so is this a normal behaviour to drop packet if it doesnt have timestamp.I tried to google it but no concrete answer found.

(11 Aug '14, 23:22) kishan pandey

I'm not good at reading RFCs but I think RFC1323 says we always have to send a TSVal and echo what we've received...

3.2 TCP Timestamps Option

  TCP is a symmetric protocol, allowing data to be sent at any time
  in either direction, and therefore timestamp echoing may occur in
  either direction.  For simplicity and symmetry, we specify that
  timestamps always be sent and echoed in both directions.  For
  efficiency, we combine the timestamp and timestamp reply fields
  into a single TCP Timestamps Option.
(12 Aug '14, 03:39) mrEEde

ok,thanks mrEEde

(12 Aug '14, 04:55) kishan pandey