Bug 576657
| Summary: | Openssh does not mark QoS on traffic (it uses obsolete ToS markings) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Philip Prindeville <philipp> |
| Component: | openssh | Assignee: | Jan F. Chadima <jchadima> |
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 12 | CC: | jchadima, mgrepl, philipp, tmraz |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://philipp.fedorapeople.org/openssh-qos.patch | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-06-07 08:07:01 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. Meaning what? |
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.