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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 16 Mar 2011 14:52:47 -0400
From:	John Heffner <johnwheffner@...il.com>
To:	Carsten Wolff <carsten@...ffcarsten.de>
Cc:	Yuchung Cheng <ycheng@...gle.com>,
	David Miller <davem@...emloft.net>,
	Ilpo Jarvinen <ilpo.jarvinen@...sinki.fi>,
	Nandita Dukkipati <nanditad@...gle.com>,
	netdev@...r.kernel.org,
	Alexander Zimmermann <alexander.zimmermann@...sys.rwth-aachen.de>
Subject: Re: [PATCH] tcp: avoid cwnd moderation in undo

On Wed, Mar 16, 2011 at 12:18 PM, Carsten Wolff <carsten@...ffcarsten.de> wrote:
> Unfortunately, no. ;-) My point is, that cwnd should be moderated when the
> congestion state changes are undone after a spurious recovery has been
> detected. Reordering is only one possible reason for a false recovery. And I
> stick to that point because of the thoughts I pointed out in my mail to john,
> i.e. undo typically leading to exceptionally large segment bursts.

There's a more general discussion here as to how much it's worth
avoiding bursts at all.  What research on the subject I'm aware of is
somewhat inconclusive.  It's possible to construct scenarios where
bursting, burst suppression, or pacing each win or lose badly.  If you
can choose only one approach as one-size-fits all it's difficult with
the information at hand to pick only one.  However, I really do wonder
why it's so important to suppress bursts on congestion state undo when
other, likely far more common, sources of bursts are not suppressed.

Carsten, do you have any specific examples of cases you're concerned
about?  FWIW, there are exactly two causes for spurious retransmits:
spurious fast retransmit due to reordering, and spurious timeouts due
to a delay spike.  Are you particularly concerned with one more than
the other?

Thanks,
  -John
--
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