netdev - Re: [PATCH] Make CUBIC Hystart more robust to RTT variations

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:	Tue, 08 Mar 2011 11:43:46 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	rhee@...u.edu
Cc:	lucas.nussbaum@...ia.fr, xiyou.wangcong@...il.com,
	netdev@...r.kernel.org
Subject: Re: [PATCH] Make CUBIC Hystart more robust to RTT variations

From: Injong Rhee <rhee@...u.edu>
Date: Tue, 08 Mar 2011 10:26:36 -0500

> Thanks for updating CUBIC hystart. You might want to test the
> cases with more background traffic and verify whether this
> threshold is too conservative.

So let's get down to basics.

What does Hystart do specially that allows it to avoid all of the
problems that TCP VEGAS runs into.

Specifically, that if you use RTTs to make congestion control
decisions it is impossible to notice new bandwidth becomming available
fast enough.

Again, it's impossible to react fast enough.  No matter what you tweak
all of your various settings to, this problem will still exist.

This is a core issue, you cannot get around it.

This is why I feel that Hystart is fundamentally flawed and we should
turn it off by default if not flat-out remove it.

Distributions are turning it off by default already, therefore it's
stupid for the upstream kernel to behave differently if that's what
%99 of the world is going to end up experiencing.

--
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