QoS acts as a countermeasure by preventing flows on an anonymity-network node from interfering with each other. However, an inevitable result is that when a flow is running at less than its reserved capacity, CPU load on the node will be reduced. This induces a temperature decrease, which affects the frequency of the crystal oscillator driving the system clock. This effect can be measured remotely by requesting timestamps and deriving clock skew. This vector is not low hanging fruit  but it would be good to shut down for those who need higher assurance.
(The NFQUEUE-based fix for the latency is great beause this was a more practical real world attack)
TCP ISNs are not possible to block and needed for security anyway. Are a part of all modern OSs.
The only practical solution listed in the paper/slides 
23C3 Slide 30:
Run CPU at full load - Inefficient and must be done with care since different types of tasks can have varying temperature effects
Deployment: on host out of reach of malicious code in vm.
Can disabling c-states accomplish the same?
However, the suggestion of disabling c-states more or less obsolesces this suggestion, as the stress solution could easily decrease battery life by 2-3x, whereas I've never seen wattage even double from disabling c-states.
Another option with Linux is to use TCP sequence numbers, which are the sum of a cryptographic result and a 1 MHz clock. Over short periods, the high h gives good results, but as the cryptographic function is re-keyed every 5 minutes, maintaining long term clock skew figures is non-trivial.
- An analysis of TCP secure SN generation in Linux and its privacy issues
- Tirdad kernel module for random ISN generation
- Tor Project bug report: Add research idea for Linux TCP Initial Sequence Numbers may aid correlation
- research paper: Hot or not: revealing hidden services by their clock skew