HI all, When tcp uses reno as its congestion control algothim, it uses tp->sacked_out as dup-ack. When the third dup-ack(under default condition) comes, tcp will initiate its fast retransmition. But how about sack ? According to kernel source code comments, when sack or fack tcp option is enabled, there is no dup-ack counter. See comments for function tcp_dupack_heuristics(): http://lxr.linux.no/linux+v2.6.37/net/ipv4/tcp_input.c#L2300 So , how does tcp know the current dup-ack is the last one which triggers the fast retransmition? According to rfc3517 section 5: "Upon the receipt of the first (DupThresh - 1) duplicate ACKs, the scoreboard is to be updated as normal." "When a TCP sender receives the duplicate ACK corresponding to DupThresh ACKs, the scoreboard MUST be updated with the new SACK information (via Update ()). If no previous loss event has occurred on the connection or the cumulative acknowledgment point is beyond the last value of RecoveryPoint, a loss recovery phase SHOULD be initiated, per the fast retransmit algorithm outlined in [RFC2581]." But these sentences doesn't describe how tcp knows the current ack is the dup-threshold dup-ack. Accorrding to rfc3517 seciton 4 and isLost(Seqnum) function: "The routine returns true when either DupThresh discontiguous SACKed sequences have arrived above ’SeqNum’ or (DupThresh * SMSS) bytes with sequence numbers greater than ’SeqNum’ have been SACKed. Otherwise, the routine returns false." I think this is just what I am searching for, but I still don't know which line of code in Linux tcp protocol does this check. Can any one help me ? thks in advance. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
