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

Fast-retransmission when received one duplicate ack?

0

I found a tcp packets as follows: The third packets is a dup ack packets(includeing sack option,indicate some packets is not received),then the server retransmission the packet soon.According to the RFC,above 3 duplicate acks,the tcp sender then can retransmission the packets,why the strange happened:Fast-retransmission when received one duplicate ack?

1. "10.0.30.146"     "10.50.0.45"    "TCP"   "15974 > 2806 [ACK] Seq=31116425 Ack=1 Win=5040  Len=1260"
2. "10.0.30.146"     "10.50.0.45"    "TCP"   "15974 > 2806 [ACK] Seq=31117685 Ack=1 Win=5040  Len=1260"
3. "10.50.0.45"  "10.0.30.146"   "TCP"   "[TCP Dup ACK 36104#1] 2806 > 15974 [ACK] Seq=1 Ack=31101305 Win=131072 Len=0 SLE=31107605 SRE=31108865"
4. "10.0.30.146"     "10.50.0.45"    "TCP"   "[TCP Retransmission] 15974 > 2806 [ACK] Seq=31101305 Ack=1 Win=5040 Len=1260"
5."10.50.0.45"   "10.0.30.146"   "TCP"   "[TCP Dup ACK 36104#2] 2806 > 15974 [ACK] Seq=1 Ack=31101305 Win=131072 Len=0 SLE=31107605 SRE=31115165"
6."10.0.30.146"  "10.50.0.45"    "TCP"   "[TCP Retransmission] 15974 > 2806 [ACK] Seq=31102565 Ack=1 Win=5040  Len=1260"
7."10.50.0.45"   "10.0.30.146"   "TCP"   "[TCP Dup ACK 36104#3] 2806 > 15974 [ACK] Seq=1 Ack=31101305 Win=131072 Len=0 SLE=31107605 SRE=31116425"
8."10.0.30.146"  "10.50.0.45"    "TCP"   "[TCP Retransmission] 15974 > 2806 [ACK] Seq=31103825 Ack=1 Win=5040 Len=1260"
9."10.50.0.45"   "10.0.30.146"   "TCP"   "[TCP Dup ACK 36104#4] 2806 > 15974 [ACK] Seq=1 Ack=31101305 Win=131072 Len=0 SLE=31107605 SRE=31118945"
10."10.0.30.146"     "10.50.0.45"    "TCP"   "[TCP Retransmission] 15974 > 2806 [ACK] Seq=31105085 Ack=1 Win=5040  Len=1260"
11."10.50.0.45"  "10.0.30.146"   "TCP"   "2806 > 15974 [ACK] Seq=1 Ack=31103825 Win=131072 Len=0 SLE=31107605 SRE=31118945"
12."10.0.30.146"     "10.50.0.45"    "TCP"   "[TCP Retransmission] 15974 > 2806 [ACK] Seq=31106345 Ack=1 Win=5040  Len=1260"
13."10.50.0.45"  "10.0.30.146"   "TCP"   "2806 > 15974 [ACK] Seq=1 Ack=31105085 Win=131072 Len=0 SLE=31107605 SRE=31118945"
14."10.0.30.146"     "10.50.0.45"    "TCP"   "15974 > 2806 [ACK] Seq=31118945 Ack=1 Win=5040  Len=1260"

asked 04 Dec '12, 04:32

chinasan's gravatar image

chinasan
0668
accept rate: 0%

edited 04 Dec '12, 08:24

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237


One Answer:

1

I'd say the sender retransmits BECAUSE of the SACK option, which tells it what packet is missing... there is no reason to wait for a 3rd duplicate ACK to do a fast retransmission when SACK already tells the story.

answered 04 Dec '12, 04:47

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

You mean just one duplicate ack with sack received,the sender will re-transmission these packets?

(04 Dec '12, 05:10) chinasan

yes. SACK is the best of the three strategies because it can report exactly what part is missing, while the others can only tell up to what sequence number everything was received successfully. If you have SACK working on both stacks you do not need triple duplicate acks anymore to trigger a Fast Retransmission. SACK is "negotiated" in the TCP Three Way Handshake packets.

(04 Dec '12, 06:08) Jasper ♦♦

@Chinasan and Jasper: Not neccessarily true: SACK is a method to even faster retransmit packets if e.g. there is only a single data packet lost and thus no more ACKs incoming to trigger Fast Retransmission. That is the case, if the ACK containing SACK information is the last ACK from the data-reciever. In that case SACK triggers retransmission before Retransmission timeout.

In an out-of-order scenario you of course see a single DUP Ack containing SACK options, but because a short time period after that the next ACK tells that everything is OK, no retransmission occurs.

To sum up: SACK followed by a short time period triggers retransmission of packets, but the sending stack would always wait for further ACKs if more data is in flight to see if the DUP Ack with SACK options is just an out-of-order, or if there is really something wrong with the transmission. In that case, SACK has no timimg advantage to fast retransmission, but is definitely more precise in stating exaclty which segments need to be retransmitted

(04 Dec '12, 06:35) Landi

All I'm saying is that you can see retransmissions without a third duplicate ACK because of SACK triggering it in this case. Yes, there is the timing issue etc, but the question was why there is no more dup ACKs but still a retransmission. And that is because of the SACK :-)

(04 Dec '12, 07:26) Jasper ♦♦

Dear Jasper and Landi, I'm confused with your answers. Actually,the duplicate acks mean the out of order or packets lost,the sender just received one duplicate acks,how can judge out-of-order or lost?Sack just identified which some packets expected,which some packets are received. sorry I can not comment using my iPad,so answer my own question to ask.

(04 Dec '12, 08:14) chinasan

Dup Ack means that an acknowledge number that was seen before is seen again, acknowledging the same data again. They can both appear as a result of out-of-order arrivals as well as packet loss. Same with SACK - there can be SACK options present in dup ack packets when there is just an out-of-order situation.

Actual packet loss is basically determined by the amount of dup acks (Fast Retransmission) or existance of SACK (with a little delay to make sure the packet isn't late and really lost) or long delay ("old" Retransmission timeout)

(04 Dec '12, 08:29) Jasper ♦♦
showing 5 of 6 show 1 more comments