Code change:
Behaviours around cache durations for each MoQ entity should be defined. <ins> 4.8.3. In case of congestion, the relay will use the priorities to selectively drop the "least important" objects: if congestion is noticed, the relay will drop first the lesser priority layer.  In our example, that would mean the objects marked at priority 6.  The relay will drop all objects marked at that priority, from the first dropped object to the end of the group. if congestion persists despite dropping a first layer, the relay will start dropping the next layer, in our example the objects marked at priority 5. if congestion still persist after dropping all but the highest priority layer, the relay will have to close the group, and start relaying the next group. When dropping objects within the same priority: higher object numbers in the same group, which are later in the group, are "less important" and more likely to be dropped than objects in the same group with a lower object number.  Objects in a previous group are "less important" than objects in the current group and MAY be dropped ahead of objects in the current group. The specification above assumes that the relay can detect the onset of congestion, and has a way to drop objects.  There are several ways to achieve that result, such as sending all objects of a group in a single QUIC stream and making explicit action at the time of relaying, or mapping separate priority layers into different QUIC streams and marking these streams with different priorities.  The exact solution will have to be defined in a draft that specifies transport priorities. 4.8.4. Web conferencing systems are used on networks with well over 20% packet loss and when this happens, it is often on connections with a relatively large round trip times.  In these situtation, forward error correction or redundant transmitions are used to provide a reasonable user experience.  Often video is turned off in.  There are multiple machine learning based audio codecs in development that targeting a 2 to 3 Kbps rate. This can result in scenarios where very small audio objects are sent at a rate of several hundreds packets per second with a high network loss rate. 4.8.5. In the streaming scenarios, there is an important emphasis on resynchronization, characterized by a short distance between "access points".  This can be used for features like fast-forward or rewinding, which are common in non-real-time streaming.  For real- time streaming experiences such as watching a sport event, frequent access points allow "channel surfers" to quickly join the broadcast and enjoy the experience.  The interval between these access points will often be just a few seconds. In video encoding, each access point is mapped to a fully encoded frame that can be used as reference for the "group of blocks".  The encoding of these reference frames is typically much larger than the differential encoding of the following frames.  This creates a peak of traffic at the beginning of the group.  This peak is much easier to absorb in streaming applications that tolerate higher latencies than interactive video conferences.  In practice, many real time conferences tend to use much longer groups, resulting in higher compression ratios and smoother bandwidth consumption along with a way to request the start of a new group when needed.  Other real time conferences tend to use very short groups and just wait for the next group when needed. Of course, having longer blocks create other issues.  Realtime conferences also need to accomodate the occasional occasional late comer, or the disconnected user who want to resynchronize after a network event.  This drives a need for synchronization "between access points".  For example, rather than waiting for 30 seconds before connecting, the user might quickly download the "key" frames of the past 30 seconds and replay them in order to "synchronize" the video decoder. </ins> 4.9. 4.9.1.

Related discussion:
text: Are there scenarios in which it would be useful to be able to ingest multiple MediaStreamTracks (either audio or video)? I ask because the RUSH draft doesn't support ingestion of multiple tracks and I've been told that this is a problem by some customers. Section 2.4 A media switch, sourcing tracks that represent a subset of tracks from across all the emitters. Such subset may represent tracks representing top 5 speakers at higher qualities and lot of other tracks for rest of the emitters at lower qualities. [BA] The use of the term "media switch" suggests to me that it is forwarding tracks, rather than sourcing (e.g. transcoding) them. Can you clarify? subscribing to subset of the tracks [BA] I think there may be an implicit assumption here, which is that the receiver only indicates the track it wishes to subscribe to, rather than indicating the quality it wishes to receive. Above setup brings in following properties on the data model for the transport protocol [BA] The paragraphs that follow appear to describe different ways that the system could be implemented, rather than "properties on the data model". Do you mean to say that the design should be able to handle any of the approaches described? Media Switches to source new tracks but retain media payload from the original emitters. This implies publishing new Track IDs sourced from the SFU, with object payload unchanged from the original emitters. [BA] Is the term "source new tracks" implied by changing the Track IDs? If the payload is retained, this seems like forwarding to me, rather than "sourcing new tracks". Media Switches to propogate subset of tracks as-is from the emitters to the subscribers. This implies Track IDs to be unchanged between the emitters and the receivers. [BA] What does "as-is" mean here? Are you referring only the lack of a change in the "Track ID"? If the switch drops some frames in order to reduce quality (and bandwidth consumption) is it still "as-is"? Subscribers to explictily request multiple appropriate qualities and dynamically move between the qualtiies during the course of the session [BA] Is it a goal to be able to support such a "receiver driven" approach, as well as the other two approaches, which are sender driven?