linux-kernel - Re: [PATCH 3/3] net: TCP thin dupack

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] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0910292207540.14335@melkinkari.cs.Helsinki.FI>
Date:	Thu, 29 Oct 2009 22:14:15 +0200 (EET)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Andreas Petlund <apetlund@...ula.no>
cc:	Netdev <netdev@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>, shemminger@...tta.com,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH 3/3] net: TCP thin dupack

On Thu, 29 Oct 2009, apetlund@...ula.no wrote:

> I apologise that some of you received this mail more than once. My email
> client played a HTML-trick on me.
> 
> >> +	/* If a thin stream is detected, retransmit after first
> >> +	 * received dupack */
> >> +	if ((tp->thin_dupack || sysctl_tcp_force_thin_dupack) &&
> >> +	    tcp_dupack_heurestics(tp) > 1 && tcp_stream_is_thin(tp))
> >> +		return 1;
> >> +
> >>  	return 0;
> >>  }
> >
> > Have you tested it? ...I doubt this will work like you say and
> retransmit
> > something when the window is small. ...Besides, you should have built
> this
> > patch on top of the function rename you submitted earlier as after DaveM
> applied that this will no longer even compile...
> >
> > --
> >  i.
> >
> 
> We have performed extensive tests mapping the effect of the patch you
> commented on some months ago. Since then, the only change was the one you
> requested of switching tcp_fackets_out() with tcp_dupack_heurestics().
> After inspecting the code, I believed the effect should be equal to the
> previous, only making considerations for SACK and FACK availability.
> Please tell if this will break the intended effect, and I will modify the
> patch accordingly.

Ah, you're of course right. FACK retransmits the head always but RFC3517 
mode doesn't. I think you'd need to artificially lower (ie., to calculate)
the dupthresh (from tp->reordering) to be 1 for it to work as intented.

> Graphs from our tests of the original patch can be found at the location
> linked to below.  I have tested the new one for functionality, but have
> not et performed tests on this scope as the changes were minor. I will, of
> course, fix the function rename in the next iteration. Sorry for that.
> 
> http://folk.uio.no/apetlund/lktmp/

You curiousity, have you run this more aggressive form of early retransmit 
against the one ID gives? ...I checked your results but if I understood 
them correctly the IDish early retransmit wasn't among the variants used.

-- 
 i.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/