bugzilla-daemon at mindrot.org
2012-Jul-06 00:57 UTC
[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.
bugzilla-daemon at mindrot.org
2012-Jul-08 12:49 UTC
[Bug 1997] Add QoS to ControlPath escapes
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.