Why not keep metrics within the payload body?

[wilaw]

Firstly, I really like the establishment of a standardized metrics and logging solution for moqt. This will help with interop and debugging.

However, I have a question on why timestamp is stored in the GroupID and not in the payload body? This seems a little bit of a layer violation. In my understanding , GroupID and ObjectID are transport constructs. They are visible to relays and invariant with payload contents. In parallel applications using moqt, we don't code the media PTS into the groupID, nor chat message sequence counts, so why put an analytics metric (timestamp) into GroupID? Shouldn't it be carried as part of the payload?

Perhaps you view GroupID more like an application-defined "index".?

I realize that we have two interpretations forming with the work group on the utility and function of GroupID. I had always though it was a virtual collection of independent objects and that its value increased over time. Our current I-D defines a group as A temporal sequence of objects.and Tracks contain a sequential series of one or more groups

At what point did this interpretation change? I guess we should resolve the larger question on the meaning and utility of GroupID first before tackling this issue.

[gwendalsimon]

I agree with Will. Interestingly, the example in Section 3.1 follows Will's suggestion: Group IDs are incremental; the first object of each group provides timestamp; each other object of the group is key / value of a metric.

[afrind]

I also noticed that the timestamp is included in the payload body in the examples section.

One reason I can think to make the timestamp visible to the relay (via group ID) is so that a subscriber can join or fetch at that timestamp. However, given the granularity is in microseconds and moqt doesn't have a mechanism to say "subscribe at group >= X", I can't really see that working -- I'd need a catalog or other out of band mechanism to tell me the number to pass in subscribe to get anything.

Can you explain the motivation for using group ID like this?

[gwendalsimon]

Note that the "out-of-band mechanism to tell me the number to pass in subscribe" is what the "timeline" proposal in WARP aims to.

[afrind]

moqt doesn't have a mechanism to say "subscribe at group >= X"

Nevermind, it totally does, though perhaps moqt could be more clear about how SUBSCRIBE works when start group is not an exact match.

An alternate way to spell this would be to augment moqt with an (optional?) timestamp field for objects or groups, and allow subscribers to subscribe/fetch by name things by ID or time. There may be other applications that benefit. Would it obviate the need for a timeline track?

[gwendalsimon]

An alternate way to spell this would be to augment moqt with an (optional?) timestamp field for objects or groups, and allow subscribers to subscribe/fetch by name things by ID or time.

I am not in favor of it.

With this proposal, the relay would be in charge of keeping a table mapping timestamp to object, in addition to the table mapping groupID to object, for every track, just in case someone subscribes based on timestamp. It adds more work (processing and mainly cachekey storage) at the relay-side although it is likely that nobody ever subscribes based on timestamp.

With the "timeline" track proposal, the burden is on the end-user. In all the cases with no time-based subscription, no extra-load for anyone. If needed, the end-user can subscribe just for one group to the Timeline track to get the full map timestamp <-> groupID, which is enough to navigate in the past. It seems simpler to me.