Red Hat Bugzilla – Bug 576657
Openssh does not mark QoS on traffic (it uses obsolete ToS markings)
Last modified: 2010-06-09 02:07:44 EDT
Description of problem:
The Internet carries a variety of services, some requiring timely delivery of
traffic, and others not. The packages providing the majority of server traffic
(http, smtp, imap, ftp, etc) should mark their traffic appropriately so that
other time-sensitive protocols may be differentiated.
RFC-4594 ("Guidelines for DiffServ Service Classes") Section 4.7 designates
Ssh as a "Low-Latency Data Service Class" when used for an interactive login requiring markings AF21, AF22, or AF23; and when used for file transfer as a "High-Throughput Data Service Class", requiring markings AF11, AF12, or AF13.
Currently, Openssh uses obsolete RFC-791 markings IPTOS_LOWDELAY (0x10) for interactive traffic, and IPTOS_THROUGHPUT (0x08) for file transfer.
Version-Release number of selected component (if applicable):
Source inspection or using tcpdump on an SSH session.
Steps to Reproduce:
Packets are sent with ip_tos as 0x10 or 0x08.
Should be 0x40, 0x48, or 0x50. (Or 0x28, 0x30, 0x38 for file transfer.)
This fix as been submitted upstream for consideration:
This functionality isn't enabled until the following change is made to
+UseQoS AF11 AF22
Note: if you tunnel a lot of X connections (or VNC) over ssh, then the designations from sections 4.4 and 4.5 might be more appropriate.
Ditto for /etc/ssh/ssh_config.
Also note that this option is *not* allowed in ~/.ssh/config because of the potential for abuse. It must be set site-wide by the administrator.
I prefer to wait for upstream with the decission.
The upstream does not respond yet
(In reply to comment #2)
> The upstream does not respond yet
Indeed. That's often what happens. Sometimes it's easier to just apply a patch in a distro (via updates-testing, for instance), get people to confirm that it works reliably, and then pass this information on upstream.
A "vetted" patch with users in the field trying it out often gets paid attention to whereas an untested patch might be ignored.
Actually there is some progress in upstream, so I decided to wait. There is a probability that upstream solves the QoS/ToS correctly.
(In reply to comment #4)
> Actually there is some progress in upstream, so I decided to wait. There is a
> probability that upstream solves the QoS/ToS correctly.