netdev - Re: [PATCH/RFC] [v2] TCP: use non-delayed ACK for congestion control RTT

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:	Wed, 19 Dec 2007 11:31:25 +0000
From:	Gavin McCullagh <Gavin.McCullagh@...m.ie>
To:	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
Cc:	Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH/RFC] [v2] TCP: use non-delayed ACK for congestion	control
 RTT

Hi,

On Wed, 19 Dec 2007, Ilpo Järvinen wrote:

> Isn't it also much better this way in a case where ACK losses happened,
> taking the longest RTT in that case is clearly questionable as it
> may over-estimate considerably.

Quite so.

> However, another thing to consider is the possibility of this value being 
> used in "timeout-like" fashion in ca modules (I haven't read enough ca 
> modules code to know if any of them does that), on contrary to 
> determinating just rtt or packet's delay in which case this change seems 
> appropriate (most modules do the latter). 

I'm not aware of any, but I haven't read them all either.  I would have
thought tp->srtt was the value to use in this instance, but perhaps the
individual timestamps including delack delay are useful.

> Therefore, if timeout-like module exists one should also add
> TCP_CONG_RTT_STAMP_LONGEST for that particular module and keep using
> seq_rtt for it like previously and use ca_seq_rtt only for others.

Seems reasonable.  I'll add this.

> This part doesn't exists anymore in development tree. Please base this 
> patch (and anything in future) you intend to get included to mainline
> onto net-2.6.25 unless there's a very good reason to not do so or 
> whatever 2.6.xx is the correct net development tree at that time (if
> one exists). Thanks.

Will do.   I gather I should use the latest net- tree in future when
submitting patches.

Thanks for the helpful comments,

Gavin

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