Is it possible to prioritize ssh interactive traffic over scp traffic?

jeffbearer

I'm wondering if it's possible to prioritize ssh interactive traffic over scp traffic. I don't expect that they would look any different, but I wanted ti ask to see if I'm missing something.

danswartz

Dunno offhand, but it's possible that ssh might tags the packets with some low-latency TOS flag that scp wouldn't and you could use that.

jeffbearer

Dan,

Thanks for the tip I looked more into TOS or as it's called now DS (Differentiated Services) and it looks like this is the ticket.

http://serverfault.com/questions/146010/cisco-ios-qos-prioritize-ssh-but-not-scp
http://en.wikipedia.org/wiki/IPv4#Header (scroll to DS section)

If a ssh request packet is sent that is interactive the DS field of 0x10 or 0001 0000
If a scp request packet is sent it has the DS field of 0x08 or 0000 1000

In looking that the TOS/ DS section on that wiki link it says that the top packet is "Low Delay" which matches an option in the pfsense traffic shaping form. FYI the bottom packet mean "high throughput" which is also an option on the form.

The only question I have now for my own gratification is why does the response packets not have anything set in the DS field? Are they not needed. My expectation was that replies would also have the low delay on interactive traffic.

danswartz

what do you mean by 'response packets'? ACKs? if so, they are already prioritized high. or are you saying you don't want them to be in the bulk case?

jeffbearer

In wireshark it recognizes the ssh traffic as either SSH Requests or SSH Responses. The Responses are the encrypted data coming from the ssh server back to the client. I expected that it would also be low delay to insure a snappy CLI. but only the requests from the client are flagged with low delay. I was only watching the ssh packets not the tcp overhead (sny/ack) that accompanied it.

I'm not saying that those packets should be flagged. it just seemed counterintuitive to me when I noticed it. and would love an explanation if I can get one just so I 'get' it.

danswartz

Are you running wireshark on the network where the client is? And the server is elsewhere? If so, the ToS bits will likely be nuked on any ssh response packets. I am running openssh server, and I can clearly see low delay ToS set for packets in both directions.

jeffbearer

I was only sniffing on the client. so that might explain it. I don't understand why it would get stripped off on the reply. I guess I'll need to do more research.

danswartz

Keep in mind that intervening routers can do pretty much whatever they want to the IP datagrams…

jeffbearer

indeed, there are no internet routers in the mix, but there is an ipsec tunnel. that might explain it. thanks for helping me talk it out.