QoS marking for Openssh

[Philip A. Prindeville]

On 03/08/2010 04:55 PM, Damien Miller wrote:
> On Sat, 6 Mar 2010, Philip A. Prindeville wrote:
>
>   
>> I've been going over various services (sendmail, apache, thunderbird,
>> proftpd, cyrus, etc) trying to add QoS support.
>>
>> I'm wondering if its worth doing for Openssh, also.
>>     
> OpenSSH has labeled different ToS on interactive (IPTOS_LOWDELAY)
> and non-interactive (IPTOS_THROUGHPUT) sessions for many years.
>   

Yeah... about that...  At least on linux 2.6.20 and later, I see:

        case IP_TOS:    /* This sets both TOS and Precedence */
                if (sk->sk_type == SOCK_STREAM) {
                        val &= ~3;
                        val |= inet->tos & 3;
                }
                if (inet->tos != val) {
                        inet->tos = val;
                        sk->sk_priority = rt_tos2priority(val);
                        sk_dst_reset(sk);
                }
                break;



in net/ip4v/ip_sockglue.c.

The reason for this is that the two low-order bits have been superseded
by ECN (explicit congestion notification... see RFC-3168, Section 5).

So the value 0x02, which was previously IPTOS_LOWCOST, is no longer
valid. Which implies that the rest of the IPTOS_xxxx values LOWDELAY,
THROUGHPUT, and RELIABILITY are no longer used.

In any case, RFC's 2474, 2497, and 2598 redefine the use of the bits
0xfc... which obviously clashes with 0x1e (the previous TOS mask).

What is needed to allow users to explicitly configure QoS values for
interactive and non-interactive values? Or perhaps, what's involved in
adding an option to support this (for both ssh and sshd)?

>> Setting different priorities for ssh and scp make sense... but
>> port-forwarding complicates things.
>>
>> Should the QoS be copied out of the tunneled connection?
>>     
> No, that isn't really possible (forwarding traffic occurs on the same
> TCP connection as session traffic) and probably would be pointless since
> some devices look at the QoS on the first packet of a flow only.
>   

This is true... alas.

Which is why IPsec typically performs better in QoS sensitive scenarios,
I guess.


>> Anyone have a good idea how a connection carrying tty session traffic
>> (ssh itself), plus (for example) forwarded X and LPR connections
>> should label all 3 traffic types on the same connection?
>>     
> Thanks to what I described above, there is no good answer for this.
>
> -d
>   

True that.

Well, having "ssh myhost" mark it's traffic differently than "scp -p foo
myhost:/tmp" is still worth doing.

I'll do some digging.

Thanks,

-Philip