* How does SACK or FACK determine the time to start fast retransmition ?
@ 2012-06-20 3:40 李易
0 siblings, 0 replies; 3+ messages in thread
From: 李易 @ 2012-06-20 3:40 UTC (permalink / raw)
To: kernelnewbies
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* How does SACK or FACK determine the time to start fast retransmition?
@ 2012-06-20 14:31 LovelyLich
2012-06-21 5:59 ` Eric Dumazet
0 siblings, 1 reply; 3+ messages in thread
From: LovelyLich @ 2012-06-20 14:31 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: How does SACK or FACK determine the time to start fast retransmition?
2012-06-20 14:31 How does SACK or FACK determine the time to start fast retransmition? LovelyLich
@ 2012-06-21 5:59 ` Eric Dumazet
0 siblings, 0 replies; 3+ messages in thread
From: Eric Dumazet @ 2012-06-21 5:59 UTC (permalink / raw)
To: LovelyLich; +Cc: netdev, linux-kernel
On Wed, 2012-06-20 at 22:31 +0800, LovelyLich 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 ?
Some tcp experts out there only catch tcp related stuff if Subject
includes TCP.
You might resend your mail on netdev (not sure lkml will really help)
with following subject :
[RFC] tcp: How does SACK or FACK determine the time to start fast
retransmission?
To get more traction.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-06-21 5:59 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-20 3:40 How does SACK or FACK determine the time to start fast retransmition ? 李易
2012-06-20 14:31 How does SACK or FACK determine the time to start fast retransmition? LovelyLich
2012-06-21 5:59 ` Eric Dumazet
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.