[RFC] tcp: How does SACK or FACK determine the time to start fast retransmition?

[李易]

于 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.