A swag at the Latency Controls "Rush Delivery" policy

Ralph Weber

In the  Latency Target Recipe Example (see 5 August posting to this reflector), a “Rush Delivery” policy is proposed, but its definition is left as an exercise for the reader. The general notion is that all existing policy definitions essentially declare defeat when a latency target is not met, but this conflicts with the I/O Prioritization ideas from the October 2018 Face-to-Face which suggest that “try harder” needs some representation amongst the policies.


This posting is intended to open a discussion whose result will be input to the standardization of a “try harder” policy. FWIW The factors that motivate this initial proposal are:

  • a desire to give the normal processes a chance to succeed without super-human efforts; and
  • a recognition that standardization is not possible unless “super-human efforts” are somehow quantized.


Within these guidelines, a first-pass definition of “Rush Delivery” uses the latency target as follows.

  • While the actual command latency is less than 70% of its latency target time, nothing special happens.
  • Between 70% and 85% of the latency target time, the device avoids time-consuming actions for other commands that have latency targets notably in excess of the “Rush Delivery” command’s latency target.
  • Between 85% and 100% of the latency target, the device performs no time-consuming actions for other commands that do not have the “Rush Delivery” policy.
  • Beyond 100% of the latency target, the device performs only actions that service the “Rush Delivery” command.


Before I work to standardize the above concept, I’d like to hash out details with the participants on this reflector. Don’t hold back with your comments. I have a well-deserved reputation for chomping at the bit when it comes to writing proposals for standards.


All the best,