Mailing List Archive

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

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 5/4/22 2:40 AM, Damien Miller wrote:
> On Tue, 3 May 2022, rapier wrote:
> 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!

It certainly does. I'm trying to narrow down the failure conditions but
it seems that it may be related to using IPv6 when there is a high
enough RTT to cause a lot of inflight data. As I get more information
I'll let you know what I find out. It's probably in my code but I wanted
to get a better grip on whats happening with these values.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev