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
| ||
|
Date: Thu, 28 Aug 2008 14:30:40 -0500 From: Wenji Wu <wenji@...l.gov> To: 'Ilpo Järvinen' <ilpo.jarvinen@...sinki.fi> Cc: 'John Heffner' <johnwheffner@...il.com>, 'David Miller' <davem@...emloft.net>, 'Netdev' <netdev@...r.kernel.org> Subject: RE: about Linux adaptivly adjusting dupthresh Thanks, -----Original Message----- From: Ilpo Järvinen [mailto:ilpo.jarvinen@...sinki.fi] Sent: Thursday, August 28, 2008 1:53 PM To: Wenji Wu Cc: 'John Heffner'; 'David Miller'; 'Netdev' 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
Powered by blists - more mailing lists