Pre FastTrack, to ensure QoS, I got class-based hierarchical queues (using HTB) on both outbound and inbound paths (attached to outgoing interfaces), relying on mangling to assign classes to packets. My goals were:
upload: to ensure high priority traffic having low latency and guaranteed bandwidth (ex VoIP)
download: to ensure my pipe is not saturated resulting in high latency (buffer-bloat)
With FastTrack mangling is bypassed, and so I can’t classify packets any longer. For time being I’ve mitigated it by using PCQ & SFQ queue types. For info, I’m on asymmetric 240/30 line, hence upload is my primary concern.
My question: can I enable FastTrack on download side only, and have full processing on the upload side?
What board do you use? 240/30 does not sound like too much, there are inexpensive boards now available that can cope with that amount of traffic with ease even without FastTrack.
No you cannot, BUT you can just fast-track best effort flows and only bypass fast-track for connections that need to be prioritized above or below best effort.
You can see the way my “Fast-Track Friendly QoS script” handles this:
I get around the issue by only fast-tracking best effort packets; they can therefore be left as ‘no-mark’ and matched in that way. All packets that should be either above best effort or below best effort in terms of priority must be set to ‘accept’ before the fasttrack rule hits, and thereby those particular connections will not be fasttracked and can still be mangled and marked. That way you still get the benefit of fasttrack, especially if most of your traffic is best effort.
I’ve ended with FT marking (still in filter table) conditional on associated connection mark, which is set in mangling.
Further, looks like quite a bit of acks are processed in non-FT manner, although bulk of data goes over FT. For me that’s even a bonus, as I prefer it that way (=> prioritising acks over plain data).