Question about IPQoS Defaults
Chris Rapier
rapier at psc.edu
Fri Aug 1 04:19:19 AEST 2025
On 7/30/25 22:34, Damien Miller wrote:
> On Wed, 30 Jul 2025, Job Snijders wrote:
>
>> https://lpc.events/event/11/contributions/943/attachments/901/1780/inet_tos_lpc2021.pdf
>>
>> In relationship to commit 5ee8448a, I was disappointed to discover that
>> the Linux ecosystem appears to have undone efforts to improve the
>> interactive experience versus fixing the root cause.
>
> I guess you're referring to this?
>
> https://salsa.debian.org/ssh-team/openssh/-/blob/master/debian/patches/revert-ipqos-defaults.patch?ref_type=heads
>
> If so, then yeah - getting that sorted out would be good. At the very
> least IMO Debian should fix this by defaulting to IPQoS=none rather
> than a totally-broken legacy TOS value.
That would be it and how I found out there was some issue with the IPQoS
in my test case. Personally, it would be a lot easier to test this in a
real world environment but establishing something that would force IPv4
instead of IPv6 is a bit tricky considering there is a 250ms pause*
between the connection attempts. Fedora does not do this and I'm kind of
hoping Dmitry will weigh in on this. I'd love to understand more fully
why maintainers make some of the decisions that they do.
Either way, I'm not sure implementing RFC 8305 is going to be useful in
most environments but it's an issue for some of the people I'm
supporting. It's also giving me something to do when I need a break from
writing grant proposals to the NSF that will likely end up being
rejected because their budget is being decimated. Sigh.
Chris
(* The exact delay is a runtime option but it's still difficult to find
that specific environment and having access to system I can make ssh
attempts against).
More information about the openssh-unix-dev
mailing list