| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <alpine.DEB.2.00.1111251843220.7144@melkinpaasi.cs.helsinki.fi> Date: Fri, 25 Nov 2011 18:57:14 +0200 (EET) From: "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi> To: "Esztermann, Ansgar" <Ansgar.Esztermann@...-bpc.mpg.de> cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org> Subject: Re: TCP fast retransmit On Fri, 25 Nov 2011, Esztermann, Ansgar wrote: > [originally posted to lkml] > 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. With SACKs dupacks are meaningless (just in case you craft them). Instead SACK blocks matter... but how exactly depends of if FACK is in use or not... with FACK also holes (segments not reported by sack) below highest SACK count. -- i. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists