Change:
based on the stream a packet belongs to. When an WebRTC implementation has packets to send on multiple streams <del> (with each media stream and each data channel considered as one "stream" for this purpose) that are congestion-controlled under the same congestion controller, the WebRTC implementation SHOULD cause data to be emitted in such a way that each stream at each level of priority is being given approximately twice the transmission capacity (measured in payload bytes) of the level below. Thus, when congestion occurs, a "very high" priority flow will have the ability to send 8 times as much data as a "below normal" flow if </del> <ins> that are congestion-controlled under the same congestion controller, the WebRTC implementation SHOULD cause data to be emitted in such a way that each stream at each level of priority is being given approximately twice the transmission capacity (measured in payload bytes) of the level below. Thus, when congestion occurs, a "high" priority flow will have the ability to send 8 times as much data as a "very-low" priority flow if </ins> both have data to send.  This prioritization is independent of the media type.  The details of which packet to send first are implementation defined. <del> For example: If there is a very high priority audio flow sending 100 byte packets, and a normal priority video flow sending 1000 byte packets, and outgoing capacity exists for sending >5000 payload bytes, it would be appropriate to send 4000 bytes (40 packets) of audio and 1000 bytes (one packet) of video as the result of a single pass of sending decisions. </del> <ins> For example: If there is a high priority audio flow sending 100 byte packets, and a low priority video flow sending 1000 byte packets, and outgoing capacity exists for sending >5000 payload bytes, it would be appropriate to send 4000 bytes (40 packets) of audio and 1000 bytes (one packet) of video as the result of a single pass of sending decisions. </ins> <del> Conversely, if the audio flow is marked normal priority and the video flow is marked very high priority, the scheduler may decide to send 2 </del> <ins> Conversely, if the audio flow is marked low priority and the video flow is marked high priority, the scheduler may decide to send 2 </ins> video packets (2000 bytes) and 5 audio packets (500 bytes) when outgoing capacity exists for sending > 2500 payload bytes. <del> If there are two very high priority audio flows, each will be able to send 4000 bytes in the same period where a normal priority video flow is able to send 1000 bytes. </del> <ins> If there are two high priority audio flows, each will be able to send 4000 bytes in the same period where a low priority video flow is able to send 1000 bytes. </ins> Two example implementation strategies are:

Discussion:
Updated terminology.
On reading the document, I find that the term "media flow" is used where draft-ietf-avtext-rtp-grouping-taxonomy suggests "source stream". Still open what to use instead of "data flow". "Data stream"?
After reconsidering, I added a definition for "flow" instead. Let's see how that scans.
rtcweb-transport: "normal", "below normal", "high" or "very high". tsvwg-rtcweb-qos: “very low”, “low”, “medium”, “high”. WEBRTC-PC: enum RTCPriorityType { "very-low", "low", "medium", "high" }; The majority should win.