Bug 576657 - Openssh does not mark QoS on traffic (it uses obsolete ToS markings)
Openssh does not mark QoS on traffic (it uses obsolete ToS markings)
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
12
All All
low Severity low
: ---
: ---
Assigned To: Jan F. Chadima
Fedora Extras Quality Assurance
http://philipp.fedorapeople.org/opens...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-24 14:14 EDT by Philip Prindeville
Modified: 2010-06-09 02:07 EDT (History)
4 users (show)

See Also:
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: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
OpenSSH Project 1733 None None None Never

  None (edit)
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):

5.4p1

How reproducible:

Source inspection or using tcpdump on an SSH session.

Steps to Reproduce:
1.
2.
3.

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:

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

This functionality isn't enabled until the following change is made to 
/etc/ssh/sshd_config:

+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?

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