Re: [rtcweb] Some language on "prioritization"

Harald Alvestrand <> Thu, 10 April 2014 13:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E19481A01C1 for <>; Thu, 10 Apr 2014 06:14:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.528
X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EOoOjB3DFp_b for <>; Thu, 10 Apr 2014 06:14:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B67441A012D for <>; Thu, 10 Apr 2014 06:13:44 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C9FE7C51BC for <>; Thu, 10 Apr 2014 15:13:43 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HeCV9uo8LbZ5 for <>; Thu, 10 Apr 2014 15:13:42 +0200 (CEST)
Received: from (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by (Postfix) with ESMTPSA id C3A4E7C51BB for <>; Thu, 10 Apr 2014 15:13:42 +0200 (CEST)
Message-ID: <>
Date: Thu, 10 Apr 2014 15:13:41 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
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: Thu, 10 Apr 2014 13:14:07 -0000

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.)


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. --