netdev - Re: [PATCH] tcp: avoid cwnd moderation in undo

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 15 Mar 2011 17:34:56 -0700
From:	Yuchung Cheng <ycheng@...gle.com>
To:	Carsten Wolff <carsten@...ffcarsten.de>
Cc:	David Miller <davem@...emloft.net>,
	Ilpo Jarvinen <ilpo.jarvinen@...sinki.fi>,
	Nandita Dukkipati <nanditad@...gle.com>, netdev@...r.kernel.org
Subject: Re: [PATCH] tcp: avoid cwnd moderation in undo

On Tue, Mar 15, 2011 at 3:07 AM, Carsten Wolff <carsten@...ffcarsten.de> wrote:
>
> Hi,
>
> On Monday 14 March 2011, Yuchung Cheng wrote:
> > On Mon, Mar 14, 2011 at 3:06 AM, Carsten Wolff <carsten@...ffcarsten.de>
> wrote:
> > In the presence of reordering, cwnd is already moderated in Disorder
> > state before
> >  entering the (false) recovery.
>
> Sure, cwnd moderation to in_flight + 1 segment is applied in disorder state,

it's in_flight + 3 usually. the moderation first happens
tcp_try_to_open() instead of tcp_cwnd_down()

>
> because this is implementing a form of extended limited transmit.
> Nevertheless, after a reordering event that caused a spurious fast retransmit,
> there can be an undo of congestion state changes (either after recovery or
> interrupting recovery, depending on the options enabled in the connection). I
> just wanted to point out, that the moderation step happening upon an undo may
> allow a larger burst, if a previous reordering event was detected and caused
> tp->reordering to be increased.

Your point is that cwnd should be moderated on reordering (in undo or
other events). Point taken.
 My point is that cwnd does not need to be moderated on false
recoveries. Do you agree?
To implement your design, tcp_update_reordering should do
tcp_cwnd_moderation().
To implement my point, the moderations should be avoided in undo operations.

The two aren't in conflict. But there are cases that have both undo
and reordering.
Are we on the same page?

>
> > > More importantly, the prior ssthresh is restored and not affected by
> > > moderation. This means, if moderation reduces cwnd to a small value, then
> > > cwnd < ssthresh and TCP will quickly slow-start back to the previous
> > > state, without sending a big burst of segments.
>
> This is actually the more important point, because it means that the
> moderation does not negate the effects of the undo operation, as suggested by
> your patch-description.

It's a double-edge sword. Why slow-start if there is no real loss? It
hurts short
request-response type traffic performance badly b/c each undo makes cwnd = 3.
>
> False fast retransmits are mostly caused by reordering, spurious RTOs can also
> be caused by delay variations that do not exhibit reordering. Your patch
> touches all cases of spurious events. Anyway, I just mentioned reordering,
> because it is the event in which Linux already allows larger bursts of size
> tp->reordering in the moderation function (i.e. tp->reordering might be
> increased). It's also not important to me if the undo is happening duringor
> after recovery, the important question is, if burst protection in general is
> an important goal, or not (and I think it's there for a reason).
I am hoping my previous explanation make sense to you (these two points are
not in conflict).
--
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