Re: [rtcweb] Prioritization

"DRUTA, DAN" <dd5826@att.com> Thu, 01 May 2014 04:01 UTC

Return-Path: <dd5826@att.com>
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 8B1EE1A09A2 for <rtcweb@ietfa.amsl.com>; Wed, 30 Apr 2014 21:01:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Level:
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 YxeliA9QgDux for <rtcweb@ietfa.amsl.com>; Wed, 30 Apr 2014 21:01:39 -0700 (PDT)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 818131A09A0 for <rtcweb@ietf.org>; Wed, 30 Apr 2014 21:01:39 -0700 (PDT)
Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 227c1635.2b5f90c0d940.6835642.00-2431.19130198.nbfkord-smmo06.seg.att.com (envelope-from <dd5826@att.com>); Thu, 01 May 2014 04:01:38 +0000 (UTC)
X-MXL-Hash: 5361c7222ae76daa-162b3da7c521c5fe0cd21d21ef5f0abc8c0049c6
Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 5e6c1635.0.6834729.00-2320.19127564.nbfkord-smmo06.seg.att.com (envelope-from <dd5826@att.com>); Thu, 01 May 2014 04:00:38 +0000 (UTC)
X-MXL-Hash: 5361c6e62c4f2f44-ad675e0c1f951dee6d3af22c98d81f93dbe4fa2f
Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id s4140bl6031261; Wed, 30 Apr 2014 21:00:37 -0700
Received: from flpi488.ffdc.sbc.com (flpi488.ffdc.sbc.com [130.4.162.182]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id s4140XL0031224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Apr 2014 21:00:33 -0700
Received: from CAFRFD1MSGHUB9F.ITServices.sbc.com (CAFRFD1MSGHUB9F.itservices.sbc.com [135.161.21.166]) by flpi488.ffdc.sbc.com (RSA Interceptor); Thu, 1 May 2014 04:00:25 GMT
Received: from CAFRFD1MSGUSRIA.ITServices.sbc.com ([169.254.1.196]) by CAFRFD1MSGHUB9F.ITServices.sbc.com ([135.161.21.166]) with mapi id 14.03.0174.001; Wed, 30 Apr 2014 21:00:25 -0700
From: "DRUTA, DAN" <dd5826@att.com>
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Matthew Kaufman <matthew.kaufman@skype.net>
Thread-Topic: [rtcweb] Prioritization
Thread-Index: AQHPYIVkbrnol5gVYEePM17Zq0EsRJsixs2AgAAJA4CAABM3gIAABB6AgAAc5ICAAAC8gIAIIG+A///1ZcA=
Date: Thu, 01 May 2014 04:00:24 +0000
Message-ID: <4AA3A95D6033ED488F8AE4E45F47448743A2DF4A@CAFRFD1MSGUSRIA.ITServices.sbc.com>
References: <20140425084726.8812.24604.idtracker@ietfa.amsl.com> <535A21E3.7070008@alvestrand.no> <535A5ACC.9070700@viagenie.ca> <535A6151.1060501@alvestrand.no> <535A68E1.9090901@viagenie.ca> <535A78FF.20700@alvestrand.no> <535A7C73.6050701@viagenie.ca> <CABkgnnWkOGdSzP42rZ-aGjFkGDOOGOfk64rq-80GjeVPZJAqaw@mail.gmail.com> <AE1A6B5FD507DC4FB3C5166F3A05A484504DFEA3@TK5EX14MBXC298.redmond.corp.microsoft.com> <F60C5C26-CFFE-45D1-BF1A-D1C320835C8A@cisco.com>
In-Reply-To: <F60C5C26-CFFE-45D1-BF1A-D1C320835C8A@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.163.34.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=QZ3RSLnv c=1 sm=1 a=xwOvzTHDVLE4u4nGvK72ag==:17 a]
X-AnalysisOut: [=ofMgfj31e3cA:10 a=sQVNTnci9XEA:10 a=BLceEmwcHowA:10 a=kj9]
X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUA]
X-AnalysisOut: [AAA:8 a=vR12nkMaAAAA:8 a=Io4Au8LPJgGXhrALu88A:9 a=CjuIK1q_]
X-AnalysisOut: [8ugA:10 a=lZB815dzVvQA:10 a=qi9FgK3vWkoA:10]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <dd5826@att.com>
X-SOURCE-IP: [144.160.128.153]
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/r2JUcUPco4fVv5aUlLOlVAk_NdQ
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] 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: Thu, 01 May 2014 04:01:46 -0000

We discussed this a while back and to a certain extent is a split problem between the API and the protocol.

If we look from developer's point of view, they are the ones that know within their app what's more important.
For a game data channel might be more important than video where for a customer service app audio might be more important than video (could be the opposite if it's a furniture store and showing how to assemble a piece of furniture is far more important).
The point is that it starts with the API and hopefully we will get something that will give the browser a hint on the track priority.
This indication should be used for two purposes:
	1. Plug in a common congestion control between media and data within the browser implementation, try to honor this application demand and potentially balance it with other web applications competing for resources and even other applications on the same device.
	2. Allow the browser to mark the traffic accordingly so with additional network support it can be prioritized where possible e2e. It might require an out of band negotiation between the application and the network in order to request and honor the fulfilment of this kind of prioritization where possible.
The relative priority within an app is critical and I'm sure no app developer would mark all of their tracks as high knowing that it would not do any good.
Ideally we would have an algorithm implemented consistently across the board within browsers so developers would know what to expect but the algorithm must take input from the app as a factor into its decision.

Dan

-----Original Message-----
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings (fluffy)
Sent: Wednesday, April 30, 2014 2:09 PM
To: Matthew Kaufman
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Prioritization


On Apr 25, 2014, at 11:03 AM, Matthew Kaufman (SKYPE) <matthew.kaufman@skype.net> wrote:

> If a "lower priority" packet is dispatched before a "higher priority" packet in order to "prevent starvation", then what does "higher priority" mean?

I think the labels reflect what "might" happen on average and not for any particular packet. I say "might" because in some deployments it possible the values will have no effect at all and it is possible to construct bizarre environments where you could get the opposite of the desired behavior in some cases. None of that bothers me as the label still seem like the closest to helping developers request the desired treatment. With all things qos like, the best we can for is desired outcome and not what will necessarily happen on internet. 

priority might be better called "desired priority" and the values of "very low, low, med, high" might better be called "broccoli, apple, orange, cherry" - they are really just some labels that describe how the packets *might* be queued by systems they pass through.  I think the fruit labels would be more confusing to web programmers. 


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb