A group is a collection of Objects and is a sub-unit of a Track (Section 2.4). Groups SHOULD be independently useful, so Objects within a Group SHOULD NOT depend on Objects in other Groups. A Group provides a join point for subscriptions, so a subscriber that does not want to receive the entire Track can opt to receive only Groups starting from a given Group ID. Groups can contain any number of Objects.
2.3.1. Group Ordering
Within a track, the original publisher SHOULD publish Group IDs which increase with time (where "time" is defined according to the internal clock of the media being sent). In some cases, Groups will be produced in increasing order, but sent to subscribers in a different order, for example when the subscription's Group Order is Descending. Due to network reordering and the partial reliability features of MOQT, Groups can always be received out of order.
As a result, subscribers cannot infer the existence of a Group until an object in the Group is received. This can create gaps in a cache that can be filled by doing a Fetch upstream, if necessary.
Applications that cannot produce Group IDs that increase with time are limited to the subset of MOQT that does not compare group IDs. Subscribers to these Tracks SHOULD NOT use range filters which span multiple Groups in FETCH or SUBSCRIBE. SUBSCRIBE and FETCH delivery use Group Order, so a FETCH cannot deliver Groups out of order and a subscription could have unexpected delivery order if Group IDs do not increase with time.
Note that the increase in time between two groups is not defined by the protocol.