OpenSSH sets different values to the "Type of Service" field of IP headers based on whether it thinks is is handling an interactive session or an non-interactive session. If the session is interactive, it sets the TOS value to 0x10, meaning "minimize delay". If the session is not interactive, it sets the TOS value to 0x08, meaning "maximize throughput". By themselves these values do nothing, but networking systems may prioritize traffic based on the TOS values in case of congestion. A customer reported ThinLinc sessions experiencing delays or freezes when their outgoing connection became congested. The customer did some troubleshooting and found that the ThinLinc SSH traffic was de-prioritized by a Linux firewall using the pfifo_fast queueing discipline (qdisc). In their own words: > By inspecting the network traffic with tcpdump it can be seen that > thinlinc labels the IP TOS field (more precisely the whole byte > including IP precedence and MBZ) with the value 0x8 which corresponds to > the "maximize throughput" type of service, translated to the "bulk" > priority of the linux tc-pfifo_fast scheduler (band 2) which is served last.
Workarounds: Create ~/.thinlinc/config with the following contents: IPQoS nodelay Add the same line to /etc/ssh/sshd_config if your SSH server is 5.7 or newer.
A proper fix is difficult, because we only control one side of the connection. Both sides determine what the best TOS value is based on some details about the connection, and there's no way to influence the server to select a different TOS value.
This is slightly related to the work done on bug 2566, although we only concerned ourselves with TCP_NODELAY there. It looks like we need to request a TTY for the server to set the desired TOS value.
Quoting from the OpenSSH 7.8 changelog: > * ssh(1)/sshd(8): the default IPQoS used by ssh/sshd has changed. > They will now use DSCP AF21 for interactive traffic and CS1 for > bulk. For a detailed rationale, please see the commit message: > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c#rev1.284 I'm not sure how this will affects us if/when we upgrade.