Mailing List Archive

[Bug 3505] New: SSH_MSG_CHANNEL_WINDOW_ADJUST bottleneck
https://bugzilla.mindrot.org/show_bug.cgi?id=3505

Bug ID: 3505
Summary: SSH_MSG_CHANNEL_WINDOW_ADJUST bottleneck
Product: Portable OpenSSH
Version: -current
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: P5
Component: Miscellaneous
Assignee: unassigned-bugs@mindrot.org
Reporter: mindrot@dimebar.com

tl;dr: Should we increase the maximum channel window size to allow
higher throughput for WAN data?


https://github.com/openssh/openssh-portable/commit/395ecc2bdeefd86a31562dd4145f370b816814bd
committed on 2007-06-12 is still the current #define for
CHAN_TCP_WINDOW_DEFAULT.

64*32*1024 = 2 MiB, but in 2022, I predict that networks are faster on
average than in 2007.

Some examples for 2 MiB BDP:
- 200ms @ 84 mbps
- 100ms @ 168 mbps
- 50ms @ 336 mbps
- 25ms @ 671 mbps
- 12ms @ 1398 mbps
- 6ms @ 2796 mbps
- 3ms @ 5592 mbps

Not everyone runs networks which exceed these parameters, but we do on
high-latency WANs.

The problem I'm seeing is the artificial bandwidth restriction
resulting from CHAN_TCP_WINDOW_DEFAULT being supplied to channel_new's
local_window_max.

It doesn't matter how much memory is given over to TCP buffers; because
OpenSSH (and scp, and rsync) receivers limit the channel window to
2MiB, an artificial speed limit exists.

After 15 years of
#define CHAN_TCP_WINDOW_DEFAULT (64*CHAN_TCP_PACKET_DEFAULT)

is it time for an increase? If not now, when? If not an increase,
perhaps a config option?

--
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs