[rtcweb] Some language on "prioritization"

Harald Alvestrand <harald@alvestrand.no> Mon, 31 March 2014 17:09 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233E61A6F51 for <rtcweb@ietfa.amsl.com>; Mon, 31 Mar 2014 10:09:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2EO3ZSuJWmd for <rtcweb@ietfa.amsl.com>; Mon, 31 Mar 2014 10:09:01 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 9C14A1A0897 for <rtcweb@ietf.org>; Mon, 31 Mar 2014 10:08:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5A5B87C50D4 for <rtcweb@ietf.org>; Mon, 31 Mar 2014 19:08:51 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLsfYHRxUJQn for <rtcweb@ietf.org>; Mon, 31 Mar 2014 19:08:50 +0200 (CEST)
Received: from [172.28.88.100] (unknown [74.125.122.49]) by mork.alvestrand.no (Postfix) with ESMTPSA id 39DF87C50A4 for <rtcweb@ietf.org>; Mon, 31 Mar 2014 19:08:50 +0200 (CEST)
Message-ID: <5339A120.3040909@alvestrand.no>
Date: Mon, 31 Mar 2014 19:08:48 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QIUa20XHIQMfx42xxhAlDf0cci4
Subject: [rtcweb] Some language on "prioritization"
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Mar 2014 17:09:05 -0000

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

-- 
Surveillance is pervasive. Go Dark.