Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
TCP fast retransmit
78 views
Skip to first unread message
Esztermann, Ansgar
Nov 25, 2011, 5:30:01 AM11/25/11
to
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Eric Dumazet
Nov 25, 2011, 5:50:02 AM11/25/11
to
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.
> 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.
>
Could you provide a trace showing what you believe is a violation of the
standards ?
Eric Dumazet
Nov 25, 2011, 8:10:02 AM11/25/11
to
Le vendredi 25 novembre 2011 à 13:55 +0100, Esztermann, Ansgar a écrit :
> 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-...@vger.kernel.org.
Please start a new thread on net...@vger.kernel.org to reach network
guys.
> 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):
>
> >
> > Could you provide a trace showing what you believe is a violation of the
> > standards ?
>
> 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-...@vger.kernel.org.
Please start a new thread on net...@vger.kernel.org to reach network
guys.
0 new messages