Draft: rtcweb-transports

Commentary: 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 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 .
Terminology for RTP sources is taken fromRFC7656 .
The WebRTC prioritization model is that the application tells the
WebRTC implementation about the priority of media and data flows
through an API.
The priority associated with a media or data flow is classified as
"normal", "below normal", "high" or "very high".  There are only four
priority levels at the API.
The WebRTC prioritization model is that the application tells the
WebRTC implementation about the priority of media and data that is
controlled from the API.
In this context, a "flow" is used for the units that are given a
specific priority through the WebRTC API.
For media, a "media flow", which can be an "audio flow" or a "video
flow", is what RFC7656 calls a "media source", which results in a
"source RTP stream" and one or more "redundancy RTP streams".  This
specification does not describe prioritization between the RTP
streams that come from a single "media source".
A "data flow" is the outgoing data on a single WebRTC data channel.
The priority associated with a media flow or data flow is classified
as "very-low", "low", "medium or "high".  There are only four
priority levels at the API.
When an WebRTC implementation has packets to send on multiple streams
(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
both have data to send.  This prioritization is independent of the
media type.  The details of which packet to send first are
implementation defined.
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.
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
video packets (2000 bytes) and 5 audio packets (500 bytes) when
outgoing capacity exists for sending > 2500 payload bytes.
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.
When an WebRTC implementation has packets to send on multiple streams
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
both have data to send.  This prioritization is independent of the
media type.  The details of which packet to send first are
implementation defined.
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.
Conversely, if the audio flow is marked low priority and the video
flow is marked high priority, the scheduler may decide to send 2
video packets (2000 bytes) and 5 audio packets (500 bytes) when
outgoing capacity exists for sending > 2500 payload bytes.
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.