Re: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.

Re: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.

[David Miller]

From: Komuro <komurojun@nifty.com>
Date: Sun, 14 Oct 2007 07:36:58 +0900

> 
> Dear David
> 
> The patch "[TCP]: Set initial_ssthresh default to zero in Cubic and BIC."
> is not very safe.
> 
> With this patch, ftp-transfer stops in my system.
> (vsftpd-2.0.5-8)
> 
> Please revert this patch.

No, I will not revert it with so little information, that would be a
knee-jerk reaction.

Let's anaylyze the problem first.  Please:

1) Send this report to the correct place, which is netdev@vger.kernel.org,
   so that the networking developers can analyze the bug.  Most of
   the core networking developers do not read linux-kernel so they
   did not see your report.

2) Provide a test case that the developers can use the precisely
   reproduce the problem.  Your problem may be dependant upon the
   remote system or infrastructure such as firewalls that sit between
   your machine and the remote one, so it may instead be useful
   to provide a tcpdump of the failing transfer.

I suspect some intermediate node, such as a firewall, is corrupting
your connection and causing the transfer to fail, and thus reverting
the BIC/CUBIC patch is just a workaround.

There are no other reports like your's and that change has been in
the tree for long enough to get substantial exposure.

Re: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Sat, 13 Oct 2007 15:52:11 -0700 (PDT)

> From: Komuro <komurojun@nifty.com>
> Date: Sun, 14 Oct 2007 07:36:58 +0900

BTW, even my reply didn't reach him, nifty.com reports "user unknown"
for him.

I really, truly, suspect therefore that he has other kinds of issues
at his site :-)

Re: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.

[Komuro]

Dear David

>Komuro, every single email I sent to you bounces with "user unknown",
>I bet it is some spam filter or similar that doesn't like the
>fact that I lack reverse DNS.

>From mailing-list-archive,
I can read your email.

Best Regards
Komuro

> Dear David
> 
> Actually, tcp_sk(sk)->snd_ssthresh is not initialized,
> if initial_ssthresh is 0.
> 
> The patch should be
> 
>  static void bictcp_init(struct sock *sk)
>  {
>  	bictcp_reset(inet_csk_ca(sk));
> -	if (initial_ssthresh)
> -		tcp_sk(sk)->snd_ssthresh = initial_ssthresh;
> +
> +	tcp_sk(sk)->snd_ssthresh = initial_ssthresh;
>  }
> 
> Best Regards
> Komuro
> 
> > 
> > Dear David
> > 
> > The patch "[TCP]: Set initial_ssthresh default to zero in Cubic and BIC."
> > is not very safe.
> > 
> > With this patch, ftp-transfer stops in my system.
> > (vsftpd-2.0.5-8)
> > 
> > Please revert this patch.
> > 
> > 
> > Best Regards
> > Komuro
> > 
> > >commit 66e1e3b20cbbf99da63e6c1af0fc6d39c2ed099a
> > >Author: David S. Miller <davem@sunset.davemloft.net>
> > >Date:   Wed Jun 13 01:03:53 2007 -0700
> > >
> > >    [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.
> > >    
> > >    Because of the current default of 100, Cubic and BIC perform very
> > >    poorly compared to standard Reno.
> > >    
> > >    In the worst case, this change makes Cubic and BIC as aggressive as
> > >    Reno.  So this change should be very safe.
> > >    
> > >    Signed-off-by: David S. Miller <davem@davemloft.net>
> > >
> > >diff --git a/net/ipv4/tcp_bic.c b/net/ipv4/tcp_bic.c
> > >index 281c9f9..dd9ef65 100644
> > >--- a/net/ipv4/tcp_bic.c
> > >+++ b/net/ipv4/tcp_bic.c
> > >@@ -29,7 +29,7 @@ static int fast_convergence = 1;
> > > static int max_increment = 16;
> > > static int low_window = 14;
> > > static int beta = 819;		/* = 819/1024 (BICTCP_BETA_SCALE) */
> > >-static int initial_ssthresh = 100;
> > >+static int initial_ssthresh;
> > > static int smooth_part = 20;
> > > 
> > > module_param(fast_convergence, int, 0644);
> > >diff --git a/net/ipv4/tcp_cubic.c b/net/ipv4/tcp_cubic.c
> > >index 1422448..ebfaac2 100644
> > >--- a/net/ipv4/tcp_cubic.c
> > >+++ b/net/ipv4/tcp_cubic.c
> > >@@ -29,7 +29,7 @@
> > > static int fast_convergence __read_mostly = 1;
> > > static int max_increment __read_mostly = 16;
> > > static int beta __read_mostly = 819;	/* = 819/1024 (BICTCP_BETA_SCALE) */
> > >-static int initial_ssthresh __read_mostly = 100;
> > >+static int initial_ssthresh __read_mostly;
> > > static int bic_scale __read_mostly = 41;
> > > static int tcp_friendliness __read_mostly = 1;
> > > 
> 
> 
> -- 
> Komuro <komurojun@nifty.com>


-- 
Komuro <komurojun@nifty.com>

Re: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.

[David Miller]

From: Komuro <komurojun@nifty.com>
Date: Sun, 14 Oct 2007 13:28:51 +0900

> 
> Dear David
> 
> >Komuro, every single email I sent to you bounces with "user unknown",
> >I bet it is some spam filter or similar that doesn't like the
> >fact that I lack reverse DNS.
> 
> >From mailing-list-archive,
> I can read your email.

Then why is your site sending everyone back bounces like the
following, when email is sent to you?

<komurojun@nifty.com>: host mx.nifty.com[202.248.238.10] said: 550 5.1.1
    <komurojun@nifty.com>... User unknown (in reply to RCPT TO command)

Re: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.

[Komuro]

Dear David

Sorry, my mailer's mail-address setting is wrong.


Best Regards
Komuro

Re: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.

[David Miller]

From: Komuro <komurojun-mbn@nifty.com>
Date: Sun, 14 Oct 2007 13:53:56 +0900

> Sorry, my mailer's mail-address setting is wrong.

Thank you for fixing this :-)

Re: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.

[Komuro]

Dear shemminger

>In which case it is zero because that is the default value.

The default value of snd_ssthresh is 0x7fffffff, isn't it?

[linux/net/ipv4/tcp_ipv4.c]
static int tcp_v4_init_sock(struct sock *sk)
...
        tp->snd_ssthresh = 0x7fffffff;  /* Infinity */
...

Best Regards
Komuro


> 
> Actually, tcp_sk(sk)->snd_ssthresh is not initialized,
> if initial_ssthresh is 0.
> 
> The patch should be
> 
>  static void bictcp_init(struct sock *sk)
>  {
>  	bictcp_reset(inet_csk_ca(sk));
> -	if (initial_ssthresh)
> -		tcp_sk(sk)->snd_ssthresh = initial_ssthresh;
> +
> +	tcp_sk(sk)->snd_ssthresh = initial_ssthresh;
>  }
>

Re: [NOT VERY SAFE] [TCP]: Set initial_ssthresh default to zero in Cubic and BIC.

[Stephen Hemminger]

On Mon, 15 Oct 2007 21:59:49 +0900
Komuro <komurojun-mbn@nifty.com> wrote:

> Dear shemminger
> 
> >In which case it is zero because that is the default value.
> 
> The default value of snd_ssthresh is 0x7fffffff, isn't it?
> 
> [linux/net/ipv4/tcp_ipv4.c]
> static int tcp_v4_init_sock(struct sock *sk)
> ...
>         tp->snd_ssthresh = 0x7fffffff;  /* Infinity */
> ...
> 
> Best Regards
> Komuro
> 
> 

Yes that value means that TCP stays in slow start until the first loss.
This makes TCP behave as expected in the RFC's.

-- 
Stephen Hemminger <shemminger@linux-foundation.org>

Re: [BUG kernel 2.6.25-rc3 IPV6] ping6 -I eth0 ff02::1 causes system hang.

[YOSHIFUJI Hideaki / 吉藤英明]

Switch to netdev.

In article <20080302210716.69727582.komurojun-mbn@nifty.com> (at Sun, 2 Mar 2008 21:07:16 +0900), Komuro <komurojun-mbn@nifty.com> says:

> On kernel 2.6.25-rc3, IPV6 multicast ping causes system hang
> after sending several multicast ping packet.
> 
> >ping6 -I eth0 ff02::1 
> 
> This problem does not happen on kernel 2.6.24.
> (does not depend on NIC)

Hmm, I've never seen this on our testlab.  Anyone else?
It would be great if you have chance to bisect it...

--yoshfuji

Re: Re: [BUG kernel 2.6.25-rc3 IPV6] ping6 -I eth0 ff02::1 causes system hang.

[Komuro]

Hi,

CONFIG_IPV6=y
but other IPV6 option is all not set.
in my configuration(.config)


>It would be great if you have chance to bisect it...

I don't have enough time on week-days ...


Best Regards
Komuro


>
>Switch to netdev.
>
>In article <20080302210716.69727582.komurojun-mbn@nifty.com> (at Sun, 2 Mar 2
008 21:07:16 +0900), Komuro <komurojun-mbn@nifty.com> says:
>
>> On kernel 2.6.25-rc3, IPV6 multicast ping causes system hang
>> after sending several multicast ping packet.
>> 
>> >ping6 -I eth0 ff02::1 
>> 
>> This problem does not happen on kernel 2.6.24.
>> (does not depend on NIC)
>
>Hmm, I've never seen this on our testlab.  Anyone else?
>It would be great if you have chance to bisect it...
>
>--yoshfuji

Re: [BUG kernel 2.6.25-rc3 IPV6] ping6 -I eth0 ff02::1 causes system hang.

[Brian Haley]

>> On kernel 2.6.25-rc3, IPV6 multicast ping causes system hang
>> after sending several multicast ping packet.
>>
>>> ping6 -I eth0 ff02::1 
>> This problem does not happen on kernel 2.6.24.
>> (does not depend on NIC)
> 
> Hmm, I've never seen this on our testlab.  Anyone else?

Not here.  I tried just CONFIG_IPV6=y as well.

-Brian

Re: [BUG kernel 2.6.25-rc3 IPV6] ping6 -I eth0 ff02::1 causes system hang.

[Andrew Morton]

On Sun, 2 Mar 2008 21:07:16 +0900 Komuro <komurojun-mbn@nifty.com> wrote:

> Hi,
> 
> On kernel 2.6.25-rc3, IPV6 multicast ping causes system hang
> after sending several multicast ping packet.
> 
> >ping6 -I eth0 ff02::1 
> 
> This problem does not happen on kernel 2.6.24.
> (does not depend on NIC)
> 

Let's cc the netdev list..

I tried it with 2.6.25-rc3-mm1 and got:

t61p:/home/akpm> ping6 -I eth0 ff02::1 
PING ff02::1(ff02::1) from fe80::215:58ff:fec6:dc4b eth0: 56 data bytes
64 bytes from fe80::215:58ff:fec6:dc4b: icmp_seq=1 ttl=64 time=0.059 ms
64 bytes from fe80::219:d1ff:fe04:8f42: icmp_seq=1 ttl=64 time=1.74 ms (DUP!)
64 bytes from fe80::214:51ff:fe67:55ef: icmp_seq=1 ttl=64 time=2.42 ms (DUP!)
64 bytes from fe80::202:b3ff:fe8f:a731: icmp_seq=1 ttl=64 time=4.72 ms (DUP!)
64 bytes from fe80::211:24ff:fe71:cbe4: icmp_seq=1 ttl=64 time=451 ms (DUP!)
64 bytes from fe80::215:58ff:fec6:dc4b: icmp_seq=2 ttl=64 time=0.090 ms
64 bytes from fe80::202:b3ff:fe8f:a731: icmp_seq=2 ttl=64 time=0.499 ms (DUP!)
64 bytes from fe80::214:51ff:fe67:55ef: icmp_seq=2 ttl=64 time=0.542 ms (DUP!)
64 bytes from fe80::219:d1ff:fe04:8f42: icmp_seq=2 ttl=64 time=0.576 ms (DUP!)
64 bytes from fe80::211:24ff:fe71:cbe4: icmp_seq=2 ttl=64 time=0.609 ms (DUP!)
64 bytes from fe80::215:58ff:fec6:dc4b: icmp_seq=3 ttl=64 time=0.086 ms
64 bytes from fe80::202:b3ff:fe8f:a731: icmp_seq=3 ttl=64 time=0.484 ms (DUP!)
64 bytes from fe80::214:51ff:fe67:55ef: icmp_seq=3 ttl=64 time=0.527 ms (DUP!)
64 bytes from fe80::219:d1ff:fe04:8f42: icmp_seq=3 ttl=64 time=0.561 ms (DUP!)
64 bytes from fe80::211:24ff:fe71:cbe4: icmp_seq=3 ttl=64 time=0.595 ms (DUP!)
64 bytes from fe80::215:58ff:fec6:dc4b: icmp_seq=4 ttl=64 time=0.084 ms
64 bytes from fe80::202:b3ff:fe8f:a731: icmp_seq=4 ttl=64 time=0.314 ms (DUP!)
64 bytes from fe80::214:51ff:fe67:55ef: icmp_seq=4 ttl=64 time=0.352 ms (DUP!)
64 bytes from fe80::211:24ff:fe71:cbe4: icmp_seq=4 ttl=64 time=0.386 ms (DUP!)
64 bytes from fe80::219:d1ff:fe04:8f42: icmp_seq=4 ttl=64 time=0.420 ms (DUP!)
64 bytes from fe80::215:58ff:fec6:dc4b: icmp_seq=5 ttl=64 time=0.106 ms
64 bytes from fe80::202:b3ff:fe8f:a731: icmp_seq=5 ttl=64 time=0.551 ms (DUP!)
64 bytes from fe80::214:51ff:fe67:55ef: icmp_seq=5 ttl=64 time=0.593 ms (DUP!)
64 bytes from fe80::219:d1ff:fe04:8f42: icmp_seq=5 ttl=64 time=0.627 ms (DUP!)
64 bytes from fe80::211:24ff:fe71:cbe4: icmp_seq=5 ttl=64 time=0.661 ms (DUP!)
^C
--- ff02::1 ping statistics ---
5 packets transmitted, 5 received, +20 duplicates, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.059/18.754/451.249/88.287 ms

Re: [BUG kernel 2.6.25-rc3 IPV6] ping6 -I eth0 ff02::1 causes system hang.

[Komuro]

Hi,

>Hmm, I've never seen this on our testlab.  Anyone else?

Could you send 20(twenty) or more ping packets?


>It would be great if you have chance to bisect it...On Sun, 2 Mar 2008 21:07:16 +0900

The bad commit is below.

69cc64d8d92bf852f933e90c888dfff083bd4fc9 is first bad commit
commit 69cc64d8d92bf852f933e90c888dfff083bd4fc9
Author: David S. Miller <davem@davemloft.net>
Date:   Mon Feb 11 21:45:44 2008 -0800

    [NDISC]: Fix race in generic address resolution

    Frank Blaschka provided the bug report and the initial suggested fix
    for this bug.  He also validated this version of this fix.




> Hi,
> 
> On kernel 2.6.25-rc3, IPV6 multicast ping causes system hang
> after sending several multicast ping packet.
> 
> >ping6 -I eth0 ff02::1 
> 
> This problem does not happen on kernel 2.6.24.
> (does not depend on NIC)

 
Best Regards
Komuro
 
 

Re: [BUG kernel 2.6.25-rc3 IPV6] ping6 -I eth0 ff02::1 causes system hang.

[Komuro]

Hi,

sorry, this problem exist on 2.6.25-rc2.
but it seems to be fixed on 2.6.25-rc3.


Best Regards
Komuro

> Hi,
> 
> >Hmm, I've never seen this on our testlab.  Anyone else?
> 
> Could you send 20(twenty) or more ping packets?
> 
> 
> >It would be great if you have chance to bisect it...On Sun, 2 Mar 2008 21:07:16 +0900
> 
> The bad commit is below.
> 
> 69cc64d8d92bf852f933e90c888dfff083bd4fc9 is first bad commit
> commit 69cc64d8d92bf852f933e90c888dfff083bd4fc9
> Author: David S. Miller <davem@davemloft.net>
> Date:   Mon Feb 11 21:45:44 2008 -0800
> 
>     [NDISC]: Fix race in generic address resolution
> 
>     Frank Blaschka provided the bug report and the initial suggested fix
>     for this bug.  He also validated this version of this fix.
> 
> 
> 
> 
> > Hi,
> > 
> > On kernel 2.6.25-rc3, IPV6 multicast ping causes system hang
> > after sending several multicast ping packet.
> > 
> > >ping6 -I eth0 ff02::1 
> > 
> > This problem does not happen on kernel 2.6.24.
> > (does not depend on NIC)
> 
>  
> Best Regards
> Komuro
>  
>  
> 


-- 
Komuro <komurojun-mbn@nifty.com>

Re: [BUG kernel 2.6.25-rc3 IPV6] ping6 -I eth0 ff02::1 causes system hang.

[David Miller]

From: Komuro <komurojun-mbn@nifty.com>
Date: Sat, 8 Mar 2008 13:44:10 +0900

> The bad commit is below.
> 
> 69cc64d8d92bf852f933e90c888dfff083bd4fc9 is first bad commit
> commit 69cc64d8d92bf852f933e90c888dfff083bd4fc9
> Author: David S. Miller <davem@davemloft.net>
> Date:   Mon Feb 11 21:45:44 2008 -0800
> 
>     [NDISC]: Fix race in generic address resolution
> 
>     Frank Blaschka provided the bug report and the initial suggested fix
>     for this bug.  He also validated this version of this fix.

This was a known bad commit and got reverted more than a week ago.