Re: [rtcweb] Some language on "prioritization"

[Harald Alvestrand <[e-mail]>]

On 04/11/2014 09:01 AM, Michael Tuexen wrote:
> On 10 Apr 2014, at 15:13, Harald Alvestrand <[e-mail]> wrote:
>
>> 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.
> The text reads good to me.
>>> -- 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. --
> No sure about this TODO. The priorities in draft-ietf-tsvwg-sctp-prpolicies are
> not related to the kind of priorities you describe above. Your above apply
> also to reliable channels.

We've already settled that none of the current policies in -ndata do
what the WG wants (weighted round robin), so I think it's correct to
leave this as a TODO, and punt this to TSVWG.

>
> Best regards
> Michael
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>


-- 
Surveillance is pervasive. Go Dark.