Even if putting a timestamp on packets is too expensive for each individual packet, there are ways to mitigate that.
For example, a queue manager could put a magic timestamp packet in it's queue at periodic intervals. Say, 0.1 ms. (This number may need tuning..)
Every time a timestamp packet hits the front of the queue all packets behind it until the next timestamp marker will be at least (timestamp + something less than 1 interval) old. If that timestamp is too old you just drop the packets in the interval and move on.
Of course this solution isn't as good as individual timestamps - you can still get into situations where you're sending very old packets because there are too many packets in the intervals that you ARE processing - but I can imagine cases where this type of tradeoff may be worthwhile.
Bufferbloat: Dark Buffers in the Internet (ACM Queue)
Posted Jan 3, 2012 13:01 UTC (Tue) by etienne (subscriber, #25256)
[Link]
Or use 16 queues organised by received time to store packets, at some point queue (head) No 6 contains new packets currently arriving, it you are still sending packets from queue (tail) No 7 then throw away the whole queue No 7.
Next timeslot store new packets in queue No 7 and throw away queue No 8.