Change:
further.  In this case, the immersive content is typically referred to as volumetric media.  One way to represent the volumetric media is to use point clouds, where streaming a single object may easily <del> require a bitrate of 30 Mbps or higher.  Refer to PCC for more details. </del> <ins> require a bitrate of 30 Mbps or higher.  Refer to MPEGI and PCC for more details. </ins> 2.2.

Discussion:
NAME - is this roughly what you were expecting to see, on Issue 22? Please advise :-)
I'm having a conversation with NAME about URL, but the short summary here is that I need to tighten up some of the language about what we are saying about strangely HTTPish UDP traffic, from an observer's perspective, and to do so without starting to say things that either duplicate (bad) or contradict (worse) the QUIC manageability draft on this point. You'll note that the QUIC issue is still under discussion, so probably need to revisit this after they close their Issue. Fortunately, I bet NAME will make sure I behave ... and I appreciate that.
Is it worth also saying about the expectations networks allows streaming traffic over TCP and QUIC to flow freely? I think this could just be a short paragraph that highlights that when other variables are isolated, fairness/contention between TCP and QUIC is most likely a function of the congestion controllers at play.
I THINK the current text in this draft (as of 10 May) is consistent with the QUIC manageability draft, but it will be GREAT for us to do a final check after QUIC finishes working on their draft.
NAME - thank you for this suggestion. See what you think of the current text.
And, like magic, this just popped up on the QUIC mailing list 15 minutes ago. I swear, I could write this script! "The SNI extraction and Appendix A sections of manageability provide guidance that won't work with Chrome. I opened issues 357 and 358 about this. They should be easy to resolve. I apologize for the late notice (I haven't been keeping track of these documents closely) but I do think these do need to be addressed before publication."
The text LGTM. I'll leave it to you editors to decide and battle out where/if to land it.
NAME I'm going to do a commit that moves this text to an actual reasonable place in the draft (I'll be looking at your suggestion to put it near ABR, and I'll try to Do The Right Thing). Probably best not to merge this PR until I commit that, OK?
NAME and NAME I think this PR is ready to merge. Do either of you agree?
Since the intro says relate to quality of experience in internet video delivery.

I'm a little surprised to not see anything about the effects on video QoE caused by contention in the network, or the role that fairness between other flows and/or protocols plays on video and other applications. Finally, its been interesting to see how large content providers have reduced streaming bitrates in response to large-scale contention during the COVID pandemic, whether voluntarily or via external pressures. This is especially curious when content is distributed via ABR technologies which should accommodate switching to lower bitrates. (I've heard anecdotal reasoning that the detection of contention is too slow, but unsure if that is really true).
One of the more logical explanations of the situation I have I read: URL EU asking Netflix to drop the bitrates was a total BS IMO.
It is worth noting that some protocols rely on the transport layer bwe/cc (the ones that are TCP based) while others have to implement their own mechanisms (udp based like QUIC or RTP). In that regard, I would differentiate the loss based bwe/cc algorithms (TCP, new Reno, bbr) vs the delay based ones (copa).
I'm planning to focus a PR for this issue on fairness and contention, but defer to the "Extremely Unpredictable Usage Profiles" section, which we've recently merged into Master, for anything about CoViD-19-related impacts on network performance for streaming media. Please let me know if that's not a good plan.
OK, I'm about 10 commits (it seemed like more) into the PR for this issue, and am now thinking that I should divide what is now the "Evolution of Transport Protocols and Transport Protocol Behaviors" section into a UDP/TCP section that comes before the ABR section, because those are the protocols that people use with ABR today, and a QUIC section (that is actually "evolution") that remains after the ABR section. NAME and NAME do you have any thoughts about that? I'm pretty sure it would allow us to tighten up the discussion of interaction between ABR and transport protocol behavior in the ABR section.
Sounds reasonable to me, I think.
I'll make that split (and see if I can do that without conflicts - I think I'm only moving text in , so should be easy.
The content here is pretty good, but I think maybe goes a little out of scope for what I thought this doc should do.

I'd be in favor of more depth on the effects of congestion on video QoE. I'm agnostic on whether to drop some of the depth here on congestion control in general (it's good stuff, but reading it I feel like this is for an iccrg informational topic instead of a mops one.) Also the section location seems to be the first one after the intro. Should this move into the ABR section, maybe with a note about congestion response being the primary driver for ABR bitrate selection?