netdev - Re: about Linux adaptivly adjusting dupthresh

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]

Message-ID: <Pine.LNX.4.64.0808282135350.7618@wrl-59.cs.helsinki.fi>
Date:	Thu, 28 Aug 2008 21:53:09 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Wenji Wu <wenji@...l.gov>
cc:	'John Heffner' <johnwheffner@...il.com>,
	'David Miller' <davem@...emloft.net>,
	'Netdev' <netdev@...r.kernel.org>
Subject: Re: about Linux adaptivly adjusting dupthresh

On Thu, 28 Aug 2008, Wenji Wu wrote:

> Sorry, I made a mistake in the last post, what I mean is "algorithms
> adaptively adjust TCP reordering threshold dupthresh". 

Ah, that makes much more sense. :-)

> I understand that "Eifel algorithm" or "DSACK TCP" will adaptively adjust
> dupthresh to deal with packet reordering. Are there any other
> reordering-tolerant algorithms implemented in Linux? 

First about adaptive dupthresh:

In addition to DSACK, we use never-retransmitted block's cumulative ACKs 
to increase the dupthresh (see tcp_clean_rtx_queue). Then there's some 
newreno thing when dupacks > packets_out but I've never really figured it 
fully out if that's doing the correct thing when doing + tp->packets_out 
besides the most simple case (see tcp_check_reno_reordering).

I don't think that eifel adjusts dupthresh though it can remove ambiguity 
problem and thus we can use the never-retransmitted block acked detection 
more often.

Also, there's some added logic for small-windowed case to reduce dupthresh 
temporarily (at the smallest to 3 or whatever the default is) if window is 
not large enough to generate the incremented (see tcp_time_to_recover).

Again, I'm not too sure what you mean by "reordering tolerant", but here 
are some things that may be related:

FACK -> RFC3517 auto-fallback if reordering is detected (basically holes 
are only counted with FACK in the more-than-dupthresh check).

I guess Eifel like timestamp checking belongs to this category (in 
tcp_try_undo_partial).

If latency spike + reordering occurs, SACK FRTO might help but I think
it depends on scenario.

-- 
 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