Re: ssh, HPN extension and TCP auto-tuning

[Swift Griggs <swiftgriggs%gmail.com@localhost>]

On Wed, 20 Sep 2017, Havard Eidnes wrote:
> the OpenSSH in NetBSD has for quite a while had the "high- performance 
> networking" patches applied.

I wasn't aware of this. That's good to know. I've often wondered what 
patch sets we apply to NetBSD's SSH implementation.

> However, when you copy "in the other direction", i.e. when the remote 
> sshd is the one which is pushing the file across the network, we get an 
> average of 8.4MB/s when copying a 143MB large file,

What is on the other side? NetBSD or something else? From the context, I'm 
assuming "something else" and that the something-else has the HPN patches 
also.

> and a tcpdump + tcptrace reveals that in this case the system's 
> automatic tuning of the TCP window is indeed kicking into action.

This could be the result of some kind of router issue. Perhaps the side 
that's not working is the victim of some kind of misconfiguration. Some 
possibilities are:


* One of the routers/firewalls is doing some reassembly or "cleansing"
  the TCP frames and preventing something like window scaling.

* Path MTU discovery is failing because it's blocking the ICMP probes. So,
  your MTU is artificially smaller in one direction.

* The connection on one side is being proxied in such a way that doesn't
  allow the optimizations to kick in.

I'm sure there are a few I'm not thinking of, too.

> send space, performance improves, but again, TCP auto-tuning does not 
> appear to be kicking in. Am I alone in seeing this?

I have to say that I've had a lot of weird issues with auto-tuning on 
NetBSD but I've never been had the right case to submit a PR over it. It's 
just... squirrly. I can't give enough details to be helpful, but no, you 
aren't alone in seeing it. I've noticed similar issues, but never narrowed 
it down enough to blame NetBSD.

-Swift