Bug 7038 - OpenSSH labels ThinLinc IP traffic as valuing "throughput" over low delay (ToS)
Summary: OpenSSH labels ThinLinc IP traffic as valuing "throughput" over low delay (ToS)
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client (show other bugs)
Target Milestone: MediumPrio
Assignee: Pierre Ossman
Depends on:
Reported: 2017-09-06 17:51 CEST by Karl Mikaelsson
Modified: 2019-01-11 10:02 CET (History)
1 user (show)

See Also:
Acceptance Criteria:


Description Karl Mikaelsson cendio 2017-09-06 17:51:51 CEST
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.
Comment 2 Karl Mikaelsson cendio 2017-09-06 18:27:19 CEST

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.
Comment 3 Karl Mikaelsson cendio 2017-09-06 18:28:58 CEST
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.
Comment 4 Pierre Ossman cendio 2017-09-07 09:57:25 CEST
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.
Comment 6 Karl Mikaelsson cendio 2018-09-06 13:53:15 CEST
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.

Note You need to log in before you can comment on or make changes to this bug.