netdev - Re: 2.6.20.7 TCP cubic (and bic) initial slow start way too slow?

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:	Sat, 12 May 2007 12:45:53 -0400
From:	"SANGTAE HA" <sangtae.ha@...il.com>
To:	"Bill Fink" <billfink@...dspring.com>
Cc:	"Injong Rhee" <rhee@....ncsu.edu>,
	"Stephen Hemminger" <shemminger@...ux-foundation.org>,
	"David Miller" <davem@...emloft.net>, rhee@...u.edu,
	netdev@...r.kernel.org
Subject: Re: 2.6.20.7 TCP cubic (and bic) initial slow start way too slow?

Hi Bill,

This is the small patch that has been applied to 2.6.22.
Also, there is "limited slow start", which is an experimental RFC
(RFC3742), to surmount this large increase during slow start.
But, your kernel might not have this. Please check there is a sysctl
variable "tcp_max_ssthresh".

Thanks,
Sangtae


On 5/12/07, Bill Fink <billfink@...dspring.com> wrote:
> On Thu, 10 May 2007, Injong Rhee wrote:
>
> > Oops. I thought Bill was using 2.6.20 instead of 2.6.22 which should contain
> > our latest update.
>
> I am using 2.6.20.7.
>
> > Regarding slow start behavior, the latest version should not change though.
> > I think it would be ok to change the slow start of bic and cubic to the
> > default slow start. But what we observed is that when BDP is large,
> > increasing cwnd by two times is really an overkill. consider increasing from
> > 1024 into 2048 packets..maybe the target is somewhere between them. We have
> > potentially a large number of packets flushed into the network. That was the
> > original motivation to change slow start from the default into a more gentle
> > version. But I see the point that Bill is raising. We are working on
> > improving this behavior in our lab. We will get back to this topic in a
> > couple of weeks after we finish our testing and produce a patch.
>
> Is it feasible to replace the version of cubic in 2.6.20.7 with the
> new 2.1 version of cubic without changing the rest of the kernel, or
> are there kernel changes/dependencies that would prevent that?
>
> I've tried building and running a 2.6.21-git13 kernel, but am having
> some difficulties.  I will be away the rest of the weekend so won't be
> able to get back to this until Monday.
>
>                                                 -Bill
>
> P.S.  When getting into the the 10 Gbps range, I'm not sure there's
>       any way to avoid the types of large increases during "slow start"
>       that you mention, if you want to achieve those kinds of data
>       rates.
>
>
>
> > ----- Original Message -----
> > From: "Stephen Hemminger" <shemminger@...ux-foundation.org>
> > To: "David Miller" <davem@...emloft.net>
> > Cc: <rhee@...u.edu>; <billfink@...dspring.com>; <sangtae.ha@...il.com>;
> > <netdev@...r.kernel.org>
> > Sent: Thursday, May 10, 2007 4:45 PM
> > Subject: Re: 2.6.20.7 TCP cubic (and bic) initial slow start way too slow?
> >
> >
> > > On Thu, 10 May 2007 13:35:22 -0700 (PDT)
> > > David Miller <davem@...emloft.net> wrote:
> > >
> > >> From: rhee@...u.edu
> > >> Date: Thu, 10 May 2007 14:39:25 -0400 (EDT)
> > >>
> > >> >
> > >> > Bill,
> > >> > Could you test with the lastest version of CUBIC? this is not the
> > >> > latest
> > >> > version of it you tested.
> > >>
> > >> Rhee-sangsang-nim, it might be a lot easier for people if you provide
> > >> a patch against the current tree for users to test instead of
> > >> constantly pointing them to your web site.
> > >> -
> > >
> > > The 2.6.22 version should have the latest version, that I know of.
> > > There was small patch from 2.6.21 that went in.
>

Download attachment "tcp_cubic-2.6.20.3.patch" of type "application/octet-stream" (927 bytes)