best_before is unclear

[TimEvens]

https://github.com/Quicr/quicr-protocol-spec/blob/main/protocol.md?plain=1#L240
https://github.com/Quicr/quicr-protocol-spec/blob/main/protocol.md?plain=1#L363
https://github.com/Quicr/quicr-protocol-spec/blob/main/relay.md?plain=1#L66

best_before is vaguely defined. It's first referenced under FRAGMENT MESSAGE but not defined till later under DATAGRAM HEADER. The definition "identifies the time upto" as time, but not the value of time. Is that time since epoch in milliseconds, microseconds, ...?

The use of best_before is mentioned as being used by the relays to clear cache or consider dropping a series of fragments/offsets by group/object id if they are too old. It's a bit odd this is relative to offsets within a fragment (same group/object with offset > 0). It would make more sense that this would be relative to the first offset (zero), allowing the first to define the age for all offsets of the same fragment. Allowing to remove cache using different ages could render the complete fragment (0 - to fin) corrupt, even though all messages were received.

> Current time: 12:00:00:100000
Fragment Group ID: 1 Object Id: 1 Offset 0 Best_Before: 12:00:00.300000 UTC  -- Cleared from cache early
Fragment Group ID: 1 Object Id: 1 Offset 100 Best_Before: 12:00:00.40000000 UTC  -- Cleared from cache early

> Current time 12:00:00:600000
Fragment Group ID: 1 Object Id: 1 Offset 200 Best_Before: 12:00:02.000000 UTC
Fragment Group ID: 1 Object Id: 1 Offset 301 Best_Before: 12:00:03.000000 UTC

Constraints on the best_before should be specific to indicate that the time must increment and not go back in time. If back in time, how is that handled? Need to define max values as well. Values will drive memory usage.

Might be okay to use relative time instead of fixed time values. This would mitigate clock sync issues and should support better handling of incrementing time.

Control fragment and datagram messages use best_before. Control messages are in order, but datagram messages can be out-of-order. Receiving a positive offset before offset 0 introduces the need to handle those messages temporarily. If zero is not received within some allotted time, then the series is dropped based on some shorter timer than best_before.