Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Actually this is both easy and difficult. Easy as all you need to do in insure that no more than 50 to 100 ms of delay is added. Difficult, because this is for end-to-end latency and packets vary in size.
An example of easy: say you only have one hop and you don't want to add more than 100 ms of latency and all packets are full sized (standard) Ethernet.
For a 100 Mbps interface, 100 ms would be 10,000,000 bits or 1,250,000 bytes for about 823 (1518 byte) frames. So, you want to drop when 823 (1500 byte) packets are exceeded.
For 1 Mbps, and for same frame/packet size, you wouldn't want to exceed 8 (1500) byte packets.
An example of difficult, working out limits for each hop and not knowing frame/packet sizes. For the former you can allocate a certain proportion of the total end-to-end latency for each hop. For the latter, you might use worse case (maximum possible size of frames/packets) or use average size of frame/packets; or something between the two.
Besides setting queue depths/limits, you could also police. The number of bytes, per your latency target, would provide your Bc value for a specifc rate. I.e. 1,250,000 would be the Bc for 100 Mbps with a Tc of 100 ms. The policer would measure against actual frame/packet sizes, but you still have the problem for end-to-end, per hop, allocations.
PS:
BTW, some versions of PCoIP will adjust their rate when they detect drops. For these, you might want to RED drop before you approach your total latency limits, but with RED you again also have the queue limits dependency on frame/packet sizes.
