Request regarding CHAN_INPUT_MAX
Chris Rapier
rapier at psc.edu
Sat Apr 11 07:58:24 AEST 2026
On 4/10/26 15:42, Nico Williams wrote:
> On Fri, Apr 10, 2026 at 03:32:35PM -0400, Chris Rapier wrote:
>> By restricting the advertised window to the maximum of the OpenSSH client I
>> can at least get a ~16MB receive window. If you can increase the limit to
>> 32MB (or whatever) I can improve throughput when OpenSSH clients are sending
>> data to HPN-SSH.
>>
>> I can spend some more time nailing this down if you are potentially open to
>> this change.
>
> The problem with this sort of change is that it effectively creates the
> risk of the sorts of pathologies SSHv1 had that motivated SSHv2, that
> bulk transfers on low-bandwidth paths will swamp out interactive
> channels, causing ssh to feel unresponsive.
>
> The SSHv2 nested flow control model has been called a "hand brake", and
> it is a hand brake. But multiplexing channels without flow control has
> its own problems.
>
> "HPN" needs to be an option that can be set / reset. I don't know
> whether it should be the default or not (it should be the default for
> scp, but maybe not for sftp, and maybe not for ssh), and ideally it
> should be adaptive in some manner (but, how?), but it has to at least be
> possible to turn it off.
You can disable it with a command line switch. The code is at
https://github.com/rapier1/hpn-ssh. It's primarily aimed at bulk data
movement on high performance networks (that's where the HPN comes from).
We've not seen any issues with it interfering with interactive sessions
that you wouldn't normally see with congestion anyway.
Chris
More information about the openssh-unix-dev
mailing list