netdev - Re: TCP fast retransmit

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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