Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation

denis bider <[email protected]> writes:

> It seems to me the only known applications that might want to use
> "no-handbrake" are those that don't want to use multiplexing. I don't
> know of a different usage case.

One usecase: Make make s single general-purpose connection from my
workstation to my server, using it for one or more shell sessions, port
worfwarding, etc. I use "connection sharing", i.e., a local private unix
socket that can be used to create additional channels over the same
connection.

Then I decide to do a large file transfer, so I create a new channel
just for that purpose, and I really want it to finish as soon as
possible.

Now, this is a problem in my implementation which I haven't yet bothered
to solve, because it uses a fix and pretty small window size, and
typically I won't get close to full network utilization. So I don't know
if it's good enough to just set a much larger window size (but if it
doesn' I think that ought to solve all "no-handbrake" usecases).

> In this situation, you must stop reading from the SSH socket, which
> affects all channels.

Agreed. And we should note that the "no-handbrake" will not work well if
the bottleneck of the data flow actually is after ssh, so users need to
enable it with care. One option might be to timeout after a few seconds
and close the connection; then we kill the affected channel, without
hanging the connection indefinitely.

> The way I see it, the only clean usage scenario for this feature is
> where there's a single channel.

Also in this case, if you get overwelmed with data, you have to stop
reading the ssh socket, and hence making timely key reexchange
impossible.

> That's why I think it makes sense to negotiate it on the transport
> layer. The transport layer must be aware of this.

Maybe. but I'd prefer a solution to both the single-channel use-case and
the usecase above. I think we need to take a step back and sort out what
the use cases are. I've been thinking that the poor utilization I've
seen is simply a sign of poorly chosen window sizes in my
implementation. If it's a more general problem, we need to understand
what the usecases and failure modes are.

A different solution which I've been considering is a channel mechanism
to automatically increase the window size when the ssh flow control is
the bottleneck. It could be as easy as checking on reception of
SSH_MSG_DATA if the receive window goes down to 0, and if so increase
the size of the receive buffer and send a WINDOW_ADJUST which reflects
not delivery of data, but the increased buffer.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.