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

Peter Gutmann <[email protected]> writes:

> I would consider it a bug in the spec, indicating that there's a reserved
> field but not saying how it's meant to be handled.

I think your (and Denis) is right. Send 0, ignore received value, would
have made it actually useful.

> The latter.  Implementations would, I assume, be doing this anyway, if your
> incoming data stream is faster than what you can write to disk (or whatever),
> you use TCP's flow control to manage things.
>
> (Oh, and as Denis pointed out, I'd definitely support this one :-).

I think the basic idea is sound, but I'm not sure enabling it belongs in
the *transport* layer. Also, I'm not sure it has to be restricted to a
single channel, I think it would make sense to disable flow control
independently for a single channel or a single unidirectional flow.

One can think of this feature as (1) disabling flow control, equivalent
to using an infinite ssh window size, and (2) disabling buffering of
received data (or limiting to a small buffer). This is my understanding
of how it would work:

If you are sending data on any channel without flow control, then you have
to pause reading from all data sources when writing to the ssh
connection blocks. And when it's possible to write on the ssh socket,
you can read in a round-robin fashion from all data sources for which
you either have available window space, or for which flow-control is
disabled.

If you are receiving data on any channel without flow control, you have
to pause reading from the ssh socket while delivering received data to
its data sink.

Do we have a common understanding of how it's going to work?

Some other thoughts:

Can it be made work with "connection sharing"/"gateway mode"? There are
similar flow-control isues there already, at least in my implementation.

Is it possible to do something similar by advertising a large window
size, but keep a smaller receive buffer? And then blocking the ssh
connection (preferably with some short timeout) as needed to deliver the
data? One alternative might be a channel request saying "please give me
a very large 100 MB windows size, but you don't need to buffer it all,
instead, please just close this channel if data delivery blocks for 10s."

Regards,
/Niels

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