Re: [rtcweb] Some language on "prioritization"

[Harald Alvestrand <[e-mail]>]

Just checking... since there's been no comment to the main body of the 
text here (it's all been on the SCTP aspect), is it OK to include the 
text in my next version of the -transport draft?

(I'm not responding to Karl's comments - it's at a completely different 
level of complexity.)

        Harald

On 03/31/2014 07:08 PM, Harald Alvestrand wrote:
> I see that I have promised to sugggest language for -transport- about
> prioritization.
> Here's an attempt. References and so on to be filled in later.
>
> Comments welcome - this is a first stab!
>
> --------------------------------------------
> The RTCWEB prioritization model is that the application tells the RTCWEB
> 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 RTCWEB implementation is responsible for mapping these to protocol
> mechanics at the protocol interfaces, and to behave appropriately when
> choosing what packets to send when.
>
> [draft-dhesikan] specifies the mapping of the four levels of priority,
> combined with the media type, to DSCP markings. This marking SHOULD be
> done; the implementation MAY turn off use of DSCP markings if it detects
> symptoms of unexpected behaviour like priority inversion or blocking of
> packets with certain DSCP markings. The detection of these conditions is
> implementation dependent. (Question: Does there need to be an API knob
> to turn off DSCP markings?)
>
> When an RTCWEB implementation has packets to send on multiple streams
> that are congestion-controlled under the same congestion controller, the
> RTCWEB implementation SHOULD serve the streams in a weighted round-robin
> fashion, with each level of priority being given twice the transmission
> capacity 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, but will lead to packet loss due to full
> send buffers occuring first on the highest volume flows at any given
> priority level. The details of which packet to send first are
> implementation defined.
>
> -- TODO: Specify a relative priority scheme that makes sense with SCTP,
> with an appropriate reference. [draft-ietf-tsvwg-sctp-prpolicies]
> specifies a priority policy, but it's about discarding packets, not
> deciding which packets to send first, and it also makes it impossible to
> specify time-bounded retransmission. --
>