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