TCP fast retransmit

TCP fast retransmit

[Esztermann, Ansgar]

Hello list,

is there some documentation available on TCP fast retransmit? There seem to be quite a lot of descriptions -- from informal to scholarly papers -- on the various algorithms available to calculate the proper size of the congestion window, but I have been unable so far to find out *when* a fast retransmit is triggered. RFC 2581 states the third dupACK "should" do it, and this seems to be quoted fairly often. However, I can easily produce connections that fail to perform fast retransmit even after 5 dupACKs. Some people mention Linux uses a different (presumable more sophisticated) algorithm to trigger fast retransmits, but no-one seems to elaborate.


Thanks,

A.
-- 
Ansgar Esztermann
DV-Systemadministration
Max-Planck-Institut für biophysikalische Chemie, Abteilung 105

Re: TCP fast retransmit

[Eric Dumazet]

Le vendredi 25 novembre 2011 à 10:42 +0100, Esztermann, Ansgar a écrit :
> Hello list,
> 
> is there some documentation available on TCP fast retransmit? There
> seem to be quite a lot of descriptions -- from informal to scholarly
> papers -- on the various algorithms available to calculate the proper
> size of the congestion window, but I have been unable so far to find
> out *when* a fast retransmit is triggered. RFC 2581 states the third
> dupACK "should" do it, and this seems to be quoted fairly often.
> However, I can easily produce connections that fail to perform fast
> retransmit even after 5 dupACKs. Some people mention Linux uses a
> different (presumable more sophisticated) algorithm to trigger fast
> retransmits, but no-one seems to elaborate.
> 
I believe the RFC you gave should be the ground to your question.

Could you provide a trace showing what you believe is a violation of the
standards ?

Re: TCP fast retransmit

[Esztermann, Ansgar]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]


On Nov 25, 2011, at 11:42 , Eric Dumazet wrote:

> 
> Could you provide a trace showing what you believe is a violation of the
> standards ?

"Violation" is probably a bit on the harsh side (after all, it says "should"), but here goes (wireshark/libpcap format):
The trace has been collected on 10.208.9.87. After one ACK plus five duplicates, a retransmission is triggered -- but it takes more than 200 ms, so that would be an ordinary retransmission. The original trace is (much) longer, but I've cut it down to keep the mail small. If required, I can provide more.


Thanks,

A.

-- 
Ansgar Esztermann
DV-Systemadministration
Max-Planck-Institut für biophysikalische Chemie, Abteilung 105

[-- Attachment #2: retransmit --]
[-- Type: application/octet-stream, Size: 18524 bytes --]

Re: TCP fast retransmit

[Eric Dumazet]

Le vendredi 25 novembre 2011 à 13:55 +0100, Esztermann, Ansgar a écrit :
> On Nov 25, 2011, at 11:42 , Eric Dumazet wrote:
> 
> > 
> > Could you provide a trace showing what you believe is a violation of the
> > standards ?
> 
> "Violation" is probably a bit on the harsh side (after all, it says "should"), but here goes (wireshark/libpcap format):
> The trace has been collected on 10.208.9.87. After one ACK plus five duplicates, a retransmission is triggered -- but it takes more than 200 ms, so that would be an ordinary retransmission. The original trace is (much) longer, but I've cut it down to keep the mail small. If required, I can provide more.

Ah, I missed the fact you sent your messages to
linux-kernel@vger.kernel.org.

Please start a new thread on netdev@vger.kernel.org to reach network
guys.