Bug 576657

Summary: Openssh does not mark QoS on traffic (it uses obsolete ToS markings)
Product: [Fedora] Fedora Reporter: Philip Prindeville <philipp>
Component: opensshAssignee: Jan F. Chadima <jchadima>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 12CC: jchadima, mgrepl, philipp, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
URL: http://philipp.fedorapeople.org/openssh-qos.patch
See Also: https://bugzilla.mindrot.org/show_bug.cgi?id=1733
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-06-07 04:07:01 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Philip Prindeville 2010-03-24 14:14:54 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):


How reproducible:

Source inspection or using tcpdump on an SSH session.

Steps to Reproduce:

Actual results:

Packets are sent with ip_tos as 0x10 or 0x08.

Expected results:

Should be 0x40, 0x48, or 0x50. (Or 0x28, 0x30, 0x38 for file transfer.)

Additional info:

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.
Comment 1 Jan F. Chadima 2010-03-25 05:01:03 EDT
I prefer to wait for upstream with the decission.
Comment 2 Jan F. Chadima 2010-06-07 04:07:01 EDT
The upstream does not respond yet
Comment 3 Philip Prindeville 2010-06-07 14:46:33 EDT
(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.
Comment 4 Jan F. Chadima 2010-06-08 03:27:52 EDT
Actually there is some progress in upstream, so I decided to wait. There is a probability that upstream solves the QoS/ToS correctly.
Comment 5 Philip Prindeville 2010-06-08 10:00:28 EDT
(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.    

Meaning what?