From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neal Cardwell Subject: Re: A buggy behavior for Linux TCP Reno and HTCP Date: Fri, 21 Jul 2017 16:49:14 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Yuchung Cheng , Wei Sun , netdev To: Lisong Xu Return-path: Received: from mail-oi0-f46.google.com ([209.85.218.46]:33987 "EHLO mail-oi0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752780AbdGUUtp (ORCPT ); Fri, 21 Jul 2017 16:49:45 -0400 Received: by mail-oi0-f46.google.com with SMTP id q4so61301173oif.1 for ; Fri, 21 Jul 2017 13:49:45 -0700 (PDT) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Fri, Jul 21, 2017 at 4:27 PM, Lisong Xu wrote: > > Hi Yuchung, > > This test scenario is only one example to trigger this bug. In general, as long as cwnd <4, the undo function has this bug. Yes, personally I agree that this seems like an issue that is general enough to be worth fixing. In the sense that, if cwnd <4, then we may well be very congested. So we don't want to get hit by this bug wherein an undo of a loss recovery can cause cwnd to suddenly jump (from 1, 2, or 3) up to 4. Seems like any of the several CCs that use tcp_reno_undo_cwnd() have this bug. I guess in my mind the only question is whether we want to add a tcp_foo_undo_cwnd() and ca->loss_cwnd to every CC module to handle this issue (i.e. make every CC module handle it the way CUBIC does), or (my preference) just add a tp->loss_cwnd field so we can use shared code in tcp_reno_undo_cwnd() to get this right across all CC modules. neal