Remote Window Size

[Damien Miller]

On Tue, 3 May 2022, rapier wrote:

> Hey all,
> 
> Hopefully this is an easy question. In channels.c what is c->remote_window
> being used for? Does it correspond to c->local_window on the remote? Does it
> indicate free space in a buffer? If so which one? I'm trying to nail down a
> stalling situation.

AFAIK it is used to record the most recent peer window value (i.e. sent
via SSH2_MSG_CHANNEL_WINDOW_ADJUST) minus whatever data has been sent since
then. It is used to avoid sending more than the peer's advertised window
between receipt of SSH2_MSG_CHANNEL_WINDOW_ADJUST messages

It therefore roughly corresponds to c->local_window on the peer, but only
after you take into account data that is in-flight or sitting un-acked in
the peer's receive buffer.

I guess you'd call remote_window "the estimate of the remaining bytes
available in their last-advertised window".

> On the client I've put in a debug line into channel_input_window_adjust to
> report on the size of the c->remote_window. I've noticed that when the
> performance drops and seems to stall this value doesn't move much at all. So
> I'm wondering if this represents a buffer on the remote reaching a maximum
> size and waiting to drain.

If you can similarly instrument the peer, then it might shed some light on
it. Some possibilities:

1) heaps of data in flight (e.g. bufferbloat on intervening routers)

2) a peer with a full output buffer for the channel, e.g. if it was
   writing to a disk that is slower than the network. This will cause
   backpressure via c->local_consumed (see end of channel_handle_wfd())

3) some stupid bug where we miss a case to update c->channel_handle_wfd
   or do the math wrong in channel_check_window()

hope this helps!

-d