于 2012/6/21 16:42, Vijay Subramanian 写道: > With SACK, number of dupacks does not have much meaning. What matters is > --how the SACK scoreboard looks like i.e. which packets are tagged > Lost/Sacked/Retransmitted > -- Whether FACK is in use (this assumes holes in between sacked > packets are lost and have left the network and so we can send out more > packets) > > So, stack does not count the number of dupacks that have come in. Only > SACK blocks matter. > You can try to track the following path: > tcp_ack() deals with incoming acks and if it sees a dupack (does not > matter what number), or incoming packet contains SACK it calls > tcp_fastretrans_alert() which calls tcp_xmit_retransmit_queue(). > > tcp_xmit_retransmit_queue() decides which packets to retransmit. The > first packet to start retransmitting from is tracked in > tp->retransmit_skb_hint. > Note that the dupThresh is actually tracked by tp->reordering which > measures the reordering in the network and is not fixed at 3. So, if > more than > tp->reordering packets have been acked above a given packet, this > packet is a candidate for retransmisson. See tcp_mark_head_lost() to > see how the > reordering metric is used to mark packets as lost. This corresponds to > the check you mentioned in the RFC. > > So, window permitting, packets are sent as follows; > (a)-- Packets marked lost as per description above > (b)-- new packets (if any) > (c)-- Holes between sacked packets which are not reliably lost. > > choice between (b) and (c) is made in tcp_can_forward_retransmit(). > > Hope this helps. > Vijay > It is just I wanted! Thanks for your detailed explaination and kindness. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
