Re: [rtcweb] Some language on "prioritization"

Harald Alvestrand <> Fri, 11 April 2014 07:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B1B141A0121 for <>; Fri, 11 Apr 2014 00:23:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FjGOP6x33BPT for <>; Fri, 11 Apr 2014 00:23:29 -0700 (PDT)
Received: from ( [IPv6:2001:700:1:2::117]) by (Postfix) with ESMTP id 7EDD71A0106 for <>; Fri, 11 Apr 2014 00:23:29 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE2AC7C51F0; Fri, 11 Apr 2014 09:23:27 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SIhUfpFPM-Cz; Fri, 11 Apr 2014 09:23:27 +0200 (CEST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id BCD8C7C51EF; Fri, 11 Apr 2014 09:23:26 +0200 (CEST)
Message-ID: <>
Date: Fri, 11 Apr 2014 09:23:25 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Michael Tuexen <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Some language on "prioritization"
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Apr 2014 07:23:34 -0000

On 04/11/2014 09:01 AM, Michael Tuexen wrote:
> On 10 Apr 2014, at 15:13, Harald Alvestrand <> 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

Surveillance is pervasive. Go Dark.