SSH performance [was Re: [Curdle] SSH/QUIC draft]

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> The problem isn't TCP, it's SSH, specifically SSH's terrible flow
> control a.k.a. the SSH performance handbrake, which (for SFTP) layers
> TCP over TCP over TCP.

Well...flow control over flow control over TCP, but I assume that's
what you actually mean.

> The solution isn't to run it over a protocol that hides one layer of
> the handbrake but to fix SSH's flow control problems.

Part of the problem is that ssh _needs_ flow control.  Otherwise, a
slow receiver has no way to throttle a fast sender except TCP
back-pressure, which throttles the whole connection, not just the
offending stream.  (And connections involving slow hosts are exactly
where underlying connection sharing is most important.)

It does need to do better when the bandwidth*delay product is large,
it's true.  But throwing it out entirely is...an overreaction, I think.

> And yes, I know that in theory a fix is possible if every
> implementation everywhere is very carefully implemented and tuned to
> perform exactly the same precise dance to avoid the handbrake, but
> better would be to fix the underlying problem.

It's no different from TCP in that regard.  TCP initially had a very
simple window scheme, much like ssh's.  Then this turned out to be a
performance problem in the presence of LFNs, network connections with
high bandwidth*delay products.  But the reaction was things like PAWS
and window scaling, not throwing out TCP flow control.

ssh should learn from this experience.

I don't know what the best solution is.  My own use cases often involve
slow machines and usually involve low bw*rtt products, so I have had
little provocation to think about details.  But I do think giving up on
ssh's flow control is, at best, premature.  no-flow-control is an
interesting experiment, and it's valuable information to know that it
helps when the endpoints are fast enough that the network is the
limiting factor.  But I don't think it's a good end-game answer (though
it may be one part of it).

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B