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

Mouse <[email protected]> writes:

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

Yup.

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

Sure, but that only affects setups where connection != stream.  I don't know
about how common this is in general since I doubt anyone's done a global
survey of SSH use in practice but in embedded/SCADA it's always the case that
connection == stream, so there's no need for flow control beyond what TCP
already provides.  Which is why I can safely ignore it in my code.

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

It works just fine in the AFAIK quite common scenario that connection ==
stream.  Problem is that since embedded/SCADA SSH is typically ten to twenty
years old, none of it knows about no-flow-control.  But then again these
implementation often ignore flow control anyway because of old and/or minimal
implementations.

Peter.