All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH net 5/5] tcp: send real dupACKs by locking advertized window for non-SACK flows
Date: Wed, 7 Mar 2018 23:39:50 +0200 (EET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1803072229380.30307@whs-18.cs.helsinki.fi> (raw)
In-Reply-To: <1520453637.109662.53.camel@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1416 bytes --]

On Wed, 7 Mar 2018, Eric Dumazet wrote:

> > Currently non-SACK senders cannot identify almost any duplicate ACKsᅵ
> > because the window keeps updating for almost all ACKs. As a result,ᅵ
> > non-SACK senders end up doing loss recovery only with RTO. RTO
> > recoveryᅵ
> > without SACK is quite annoying because it potentially sendsᅵ
> > large number of unnecessary rexmits.
> 
> I get that, but switching from "always" to "never" sounds dangerous.
> 
> May I suggest you refine your patch, to maybe allow win reductions, in
> a logarithmic fashion maybe ?
> 
> This way, when you send 1000 DUPACK, only few of them would actually
> have to lower the window, and 99% of them would be considered as DUPACK
> by these prehistoric TCP stacks.

The problem I'm trying to fix is due to window increasing (of course, 
dupacks could also be masked because of decrease but that's something
I've never seen to occur in practice) so I tried to make you happy and 
change my fix to do "never increase, always decrease". However, it turns 
out that even pre-fixed code implements "never decrease" not "always 
decrease" like you thought:

static u16 tcp_select_window(struct sock *sk)
{
	...
	/* Never shrink the offered window */
        if (new_win < cur_win) {
		...
		new_win = ALIGN(cur_win, 1 << tp->rx_opt.rcv_wscale);

...Thus, I don't see my fix making the case you're worried about any
worse, AFAICT.


-- 
 i.

  reply	other threads:[~2018-03-07 21:39 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-07 12:59 [PATCH net 0/5] tcp: fixes to non-SACK TCP Ilpo Järvinen
2018-03-07 12:59 ` [PATCH net 1/5] tcp: feed correct number of pkts acked to cc modules also in recovery Ilpo Järvinen
2018-03-07 12:59 ` [PATCH net 2/5] tcp: prevent bogus FRTO undos with non-SACK flows Ilpo Järvinen
2018-03-07 19:24   ` Neal Cardwell
2018-03-07 19:54     ` Yuchung Cheng
2018-03-07 22:19       ` Ilpo Järvinen
2018-03-07 12:59 ` [PATCH net 3/5] tcp: move false FR condition into tcp_false_fast_retrans_possible() Ilpo Järvinen
2018-03-07 15:50   ` Eric Dumazet
2018-03-07 12:59 ` [PATCH net 4/5] tcp: prevent bogus undos when SACK is not enabled Ilpo Järvinen
2018-03-07 20:19   ` Neal Cardwell
2018-03-07 23:48     ` Yuchung Cheng
2018-03-09 14:11       ` Ilpo Järvinen
2018-03-09 14:32         ` Eric Dumazet
2018-03-09 15:28           ` David Miller
2018-03-09 15:23         ` David Miller
2018-03-09 19:23           ` Ilpo Järvinen
2018-03-13 10:24           ` Ilpo Järvinen
2018-03-07 12:59 ` [PATCH net 5/5] tcp: send real dupACKs by locking advertized window for non-SACK flows Ilpo Järvinen
2018-03-07 15:58   ` Eric Dumazet
2018-03-07 20:09     ` Ilpo Järvinen
2018-03-07 20:13       ` Eric Dumazet
2018-03-07 21:39         ` Ilpo Järvinen [this message]
2018-03-07 22:01           ` Eric Dumazet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.20.1803072229380.30307@whs-18.cs.helsinki.fi \
    --to=ilpo.jarvinen@helsinki.fi \
    --cc=eric.dumazet@gmail.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.