netdev - Re: [PATCH 0/9]: tcp-2.6 patchset

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:	Tue, 29 May 2007 13:19:51 -0700
From:	Stephen Hemminger <shemminger@...ux-foundation.org>
To:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>"@smtp.osdl.org
Cc:	Baruch Even <baruch@...en.org>, David Miller <davem@...emloft.net>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH 0/9]: tcp-2.6 patchset

On Tue, 29 May 2007 23:07:00 +0300 (EEST)
"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi> wrote:

> On Tue, 29 May 2007, Stephen Hemminger wrote:
> 
> > On Mon, 28 May 2007 13:27:03 +0300 (EEST)
> > "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi> wrote:
> > 
> > > On Sun, 27 May 2007, Ilpo Järvinen wrote:
> > > 
> > > [PATCH] [TCP]: Fix GSO ignorance of pkts_acked arg (cong.cntrl modules)
> > 
> > Yes, thanks for fixing this. Wonder how it affects measurements.
> 
> ...It's a bit hard to tell since dynamics change so dramatically 
> in > 0 check cases, the resulting behavior in too small value cases
> may be easier to predict... It's possible that this could explain some 
> anomalities you've been seeing in your measurements.
> 
> > > It is not very clear how SYN segments should be handled, so I
> > > choose to follow the previous implementation in this respect.
> > 
> > Since we don't invoke congestion control modules until after the SYN
> > handshake this is not a problem.
> 
> Just curious, do you mean that cc modules cannot measure, e.g., initial
> RTT through this mechanism (though they could do that in init() cb then
> I suppose)... Or do you mean that they are called already for the ACK
> that completes the SYN handshake and therefore its skb is being cleaned 
> from the queue right now (this is the case I above refer to)? 
> In the first case the decrementer code is NOP. If the latter, then it
> is just interface specification question, i.e., if SYNs are treated as 
> zero or one in num_acked for the pkts_acked callback (I have no opinion
> on this but was just trying to make sure cc modules get what they
> expect :-)). 

We don't switch a socket out of Reno until after the initial handshake.
It evolved that way, and has a couple of advantages:
 * uncomplete connections don't up module refcount so it is easier to
   debug
 * in future, we can choose congestion control to use based on route
   metric.
 
As an interface, it makes sense to keep the API with the SYN counting
as a packet.

-- 
Stephen Hemminger <shemminger@...ux-foundation.org>
-
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