[Bug 1997] New: Add QoS to ControlPath escapes

bugzilla-daemon at bugzilla.mindrot.org bugzilla-daemon at bugzilla.mindrot.org
Mon Apr 9 21:00:19 EST 2012


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

             Bug #: 1997
           Summary: Add QoS to ControlPath escapes
    Classification: Unclassified
           Product: Portable OpenSSH
           Version: 5.9p1
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: ssh
        AssignedTo: unassigned-bugs at mindrot.org
        ReportedBy: peter at digitalbrains.com


Created attachment 2143
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2143
Patch implementing %q QoS ControlPath escape

I would like a percent-escape for the QoS used for the ControlPath,
such that, for instance:

ControlMaster auto
ControlPath /home/peter/.ssh/control-%r@%h:%p-%q

would have %q expand to the (numerical) QoS value used, giving
different control sockets for different QoS settings used for the
master connection.

I have QoS and traffic shaping configured on an ADSL connection. When I
have a shell open through ssh, it will create a connection with
"interactive", i.e. high, priority. If I then start an rsync to the
same remote machine, it ought to use "bulk", i.e. low, priority.
Unfortunately it will use the master connection and blast all its data
at interactive priority, which is not intended at all.

Having a percent escape for the QoS seems to me like an effective way
to prevent this problem and still get great use out of the multiplexing
feature. Using numerical QoS values gives greater flexibility than just
discriminating between SSH's concept of interactive and non-interactive
sessions as used in the IPQoS config option.

I just had a quick browse in the source code. Currently, the knowledge
if the session is interactive/non-interactive is not yet available when
the ControlPath percent escapes are parsed. Unfortunately,
interactivity is only determined /after/ the connection has been
established, and depends on whether the remote side allows allocation
of a pty or X11 forwarding.

I have created a patch, but I am not familiar with the source, so
perhaps it is very wrong :). Only the intention of interactivity is
checked, not if a pty or X11 forwarding actually succeeded, since that
information is not available. This also means that the %q might not
match with the actual QoS used, since the latter depends on succesfully
allocating a pty/X11 forwarding.

Thanks to the developers for all your work on SSH!

Peter.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.


More information about the openssh-bugs mailing list