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

2012-06-21 Thread Vijay Subramanian
On 20 June 2012 23:33, 李易 lovelyl...@gmail.com wrote:
 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?

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

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


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

2012-06-21 Thread 李易
于 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@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies