Re: [rtcweb] Some language on "prioritization"

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Fri, 11 April 2014 07:01 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
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 8E9101A040F for <rtcweb@ietfa.amsl.com>; Fri, 11 Apr 2014 00:01:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.823
X-Spam-Level:
X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001] 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 U6PhSGB-dJZ6 for <rtcweb@ietfa.amsl.com>; Fri, 11 Apr 2014 00:01:46 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id CD7A61A00D1 for <rtcweb@ietf.org>; Fri, 11 Apr 2014 00:01:45 -0700 (PDT)
Received: from [192.168.1.103] (p54818011.dip0.t-ipconnect.de [84.129.128.17]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 9932A1C104301; Fri, 11 Apr 2014 09:01:43 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <53469905.1080302@alvestrand.no>
Date: Fri, 11 Apr 2014 09:01:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <939ACBC6-B086-4F80-987F-082A202AF5D9@lurchi.franken.de>
References: <5339A120.3040909@alvestrand.no> <53469905.1080302@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/CQ_RGsOFj5myMFd6hQ2_4LWx6O4
Cc: rtcweb@ietf.org
Subject: Re: [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: Fri, 11 Apr 2014 07:01:47 -0000

On 10 Apr 2014, at 15:13, Harald Alvestrand <harald@alvestrand.no> 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.

Best regards
Michael
>> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>