Re: [rtcweb] Some language on "prioritization"

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Fri, 04 April 2014 12:49 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 B02521A016B for <rtcweb@ietfa.amsl.com>; Fri, 4 Apr 2014 05:49:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.561
X-Spam-Level:
X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 ZjH0lqTzMi59 for <rtcweb@ietfa.amsl.com>; Fri, 4 Apr 2014 05:49:50 -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 B02DE1A0141 for <rtcweb@ietf.org>; Fri, 4 Apr 2014 05:49:49 -0700 (PDT)
Received: from [192.168.1.103] (p508F0F22.dip0.t-ipconnect.de [80.143.15.34]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id DB89E1C1047F6; Fri, 4 Apr 2014 14:49:42 +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: <CC8CDB3B-530D-40FA-A3F4-91177C64A6BF@cisco.com>
Date: Fri, 4 Apr 2014 14:49:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <B2F85E5E-D5C9-47DA-AC37-86EF5C0F011B@lurchi.franken.de>
References: <5339A120.3040909@alvestrand.no> <CABkgnnVUHUx+3wY3Dsi=UvNkUw_Es1apeMSonq7DtEg_3UKRNg@mail.gmail.com> <FBA84C78-FE8E-4FEF-8AD3-CAF24C57E512@lurchi.franken.de>, <5339AA58.9070301@alvestrand.no> <834D5209-5EEA-4001-B8ED-3835FC4D05FB@skype.net> <00af01cf4f59$fa617b90$ef2472b0$@stahl@intertex.se> <CB16B8F0-DDC2-4404-A81F-1B3101647DE9@lurchi.franken.de>, <533E729F.4000302@alvestrand.no> <CC8CDB3B-530D-40FA-A3F4-91177C64A6BF@cisco.com>
To: "Jeremy Laurenson (jlaurens)" <jlaurens@cisco.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sXLtUM7Qq9HhoC_CpF5HCojifn8
Cc: "rtcweb@ietf.org" <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, 04 Apr 2014 12:49:53 -0000

On 04 Apr 2014, at 13:55, Jeremy Laurenson (jlaurens) <jlaurens@cisco.com> wrote:

> Do we really want the default (lazy coder) behavior to be highest priority in this case?
Harald is referring to the SCTP socket API description. This won't be exposed
to the JS user. What will be exposed there needs to be defined by W3C and
will be mapped to the API of the SCTP implementation.
> 
> I assume the priority is browser-wide and so this could disrupt other app's streams?
The priories described below are only relevant for the streams of an SCTP
association. It is just a scheduler which deals with the streams of an SCTP
association.

Best regards
Michael
> 
> J
>> 
> 
> On Apr 4, 2014, at 4:52 AM, "Harald Alvestrand" <harald@alvestrand.no> wrote:
> 
>> I assume this is the scheduler envisioned in -ndata:
>> 
>>       SCTP_SS_PRIORITY:  Scheduling with different priorities is used.
>>          Streams having a higher priority will be scheduled first and
>>          when multiple streams have the same priority, the default
>>          scheduling should be used for them.  The priority can be
>>          assigned with the sctp_stream_value struct.  The higher the
>>          assigned value, the lower the priority, that is the default
>>          value 0 is the highest priority and therefore the default
>>          scheduling will be used if no priorities have been assigned.
>> 
>> 
>> 
>> This sounds like a "strict" scheduler, in that higher priority queues will starve out lower priority ones completely. I remember having the discussion at an IETF meeting about whether we wanted a "strict" scheduler or a "weighted round robin" scheduler for  this, but I wouldn't trust my memory with what the conclusion was.
>> 
>> Was the conclusion that we should do "strict" scheduling? If so, it may be best to make that consistent across the board - I had written in a "weighted" scheduler for media into the prioritization text that I started this thread with, but I think there's value to consistency.
>> 
>> (Note: -ndata has SS_PRIORITY in one place and SS_PRIO / SS_PRIO_INTER in another place. Is there a subtlety here I'm not seeing?)
>> 
>> 
>> 
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb