openssh bugs - Jul 2012 - [Bug 1997] Add QoS to ControlPath escapes

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
The problem with this is that the QoS isn't always known when the
connection is started. We have options for interactive and
non-interactive QoS values, and the decision of whether a connection is
interactive can happen well after the time when the connection is
established - e.g. a multiplexed connection or no-shell sessions that
is used for X11 forwarding.

IMO you would be better off defining multiple "Host" entries in
ssh_config for your targets that forced the use of specific QoS and
baked these into the hostname and ControlPath.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

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

--- Comment #2 from Peter Lebbing <peter at digitalbrains.com> ---
(In reply to comment #1)
> The problem with this is that the QoS isn't always known when the
> connection is started. We have options for interactive and
> non-interactive QoS values, and the decision of whether a connection
> is interactive can happen well after the time when the connection is
> established - e.g. a multiplexed connection or no-shell sessions
> that is used for X11 forwarding.
The whole problem is exactly that the QoS in the current situation
already goes wrong with a multiplexed connection. The decision whether
a connection is interactive is already too late: the session that
started the multiplexed connection now determines the QoS for all other
sessions that run over the same multiplexed connection.

So instead of completely ignoring the difference in the two arguments
to IPQoS for all sessions that join the multiplexed connection, the
ControlPath escape mitigates the problem. It would still get it wrong
in some situations.[1] 
> IMO you would be better off defining multiple "Host" entries in
> ssh_config for your targets that forced the use of specific QoS and
> baked these into the hostname and ControlPath.
That would work. But it needs entries for all systems you wish to use
with multiplexing. And I'd probably add a final entry for each host,
matching the real unqualified and qualified hostnames and turning off
multiplexing. So you don't accidentally blast all your data at the
interactive QoS when you specify the real hostname.

Thanks for your input.

[1] If I look at my own usage pattern, those situations seem to be
rare. Am I correct in thinking they are mostly related to the server
forcing a setting you didn't request? Like not getting a pty or X
forwarding.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.