TCP Dup ACK and a TCP retransmission _large packet size

Question

I do not understand why there is a DUP ACK and a TCP retransmission was intiated. i am using cisco ASA as a ptoxy for TCP connication, when i set the MTU to 1500 connection works with out any problem, but when i set the MTU to larger than 1500 i see a DUP ACK and a TCP retransmission. is it becouse the large MTU ?

1055 > x.x.x.x 10.1.23.25 TCP 60 22345→80 [ACK] Seq=1 Ack=171121 Win=64240 Len=0
1057 > x.x.x.x 10.1.23.25 TCP 60 22345→80 [ACK] Seq=1 Ack=173881 Win=64240 Len=0
1060 > x.x.x.x 10.1.23.25 TCP 60 22345→80 [ACK] Seq=1 Ack=176641 Win=63860 Len=0
1061 > x.x.x.x 10.1.23.25 TCP 60 [TCP Dup ACK 1060#1] 22345→80 [ACK] Seq=1 Ack=176641 Win=63860 Len=0
1063 >x.x.x.x 10.1.23.25 TCP 60 22345→80 [ACK] Seq=1 Ack=179401 Win=64240 Len=0
1064 > x.x.x.x 10.1.23.25 TCP 66 [TCP Dup ACK 1063#1] 22345→80 [ACK] Seq=1 Ack=179401 Win=64240 Len=0 SLE=180781 SRE=182161
1065 > 10.1.23.25 x.x.x.x TCP 4194 80→22345 [ACK] Seq=224941 Ack=1 Win=6640 Len=4140[Packet size limited during capture]
1067 > x.x.x.x 10.1.23.25 TCP 74 [TCP Dup ACK 1063#2] 22345→80 [ACK] Seq=1 Ack=179401 Win=64240 Len=0 SLE=180781 SRE=182161 SLE=184921 SRE=186301
1068 > 10.1.23.25 x.x.x.x TCP 1434 [TCP Fast Retransmission] 80→22345 [ACK] Seq=179401 Ack=1 Win=6640 Len=1380[Packet size limited during capture]
1069 > x.x.x.x 10.1.23.25 TCP 74 [TCP Dup ACK 1063#3] 22345→80 [ACK] Seq=1 Ack=179401 Win=64240 Len=0 SLE=184921 SRE=186301 SLE=189061 SRE=190441
1070 > 10.1.23.25 x.x.x.x TCP 1434 [TCP Retransmission] 80→22345 [ACK] Seq=182161 Ack=1 Win=6640 Len=1380[Packet size limited during capture]
1117 > x.x.x.x 10.1.23.25 TCP 74 [TCP Dup ACK 1063#4] 22345→80 [ACK] Seq=1 Ack=179401 Win=64240 Len=0 SLE=189061 SRE=190441 SLE=193201 SRE=194581

Answer 1

0

Unless your devices all run with Jumbo frame support enabled you cannot set an MTU greater than 1500.

answered 26 Apr '15, 06:21

Jasper ♦♦
23.8k●5●51●284
accept rate: 18%

Hi Jasper,

thank you for your answer.

actually, Jumbo frame support is enabled, and all the interfaces have the same MTU size equal to 9198.

also, from the capture I can see the scaling widows is unknown. but in the TCP hand shack is being negotiated

1624 3.175962 x.x.x.x 10.1.244.25 TCP 74 [TCP Dup ACK 1620#1] 22345→80 [ACK] Seq=1 Ack=186301 Win=63860 Len=0 SLE=193201 SRE=229081 SLE=189061 SRE=190441

Window size value: 63860

Calculated window size: 63860

Window size scaling factor: -1 (unknown)

(26 Apr '15, 06:48) RAM_R

Scaling factor -1 happens if don't have captured the tcp handshake.

(26 Apr '15, 07:25) Christian_R

yes, I cannot see the TCP handchack for this in the capture. is it possible that the reason for this behavior is the buffer limits.

(26 Apr '15, 08:02) RAM_R

Answer 2

"I do not understand why there is a DUP ACK and a TCP retransmission was intiated."

Because the client is reporting gaps using the TCP SACK option

"i am using cisco ASA as a ptoxy for TCP connication, when i set the MTU to 1500 connection works with out any problem, but when i set the MTU to larger than 1500 i see a DUP ACK and a TCP retransmission. is it becouse the large MTU ?"

Obviously yes ;-)

The negotiated MSS is 1380 bytes: The client ACKs 2*1380 bytes and the gap reports and re-tranmsissions are also for 1380 bytes segments (ASA adjusts the negotiated MSS values in the SYN packets)

"and all the interfaces have the same MTU size equal to 9198"

the maximum size for JumboFrames is 9000 bytes

TCP segmentation offload (TSO or LargeSendOffload) seems to be enabled at the sender and defining a too large MTU size might confuse this algorithm.

Regards Matthias