W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2017

Re: A very short extension spec: DSCP codepoint control

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 28 Nov 2017 18:42:30 +0100
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, public-webrtc@w3.org
Message-ID: <7c0cbc17-a801-5e97-035e-c4526a59c97d@alvestrand.no>
On 11/28/2017 06:32 PM, Sergio Garcia Murillo wrote:
> Hi Harald,
>
> I was at TPAC where Peter introduced the topic (which made a lot of
> sense to me), but I was not at IETF, so not sure about the discussions
> there.
>
> IMHO, we could provide an extension of the current API that would not
> break current behaviour (which seemed to be the main concern), in the
> way that other W3C apis have done it.
>
> It could be possible to use either the current specification to set
> both local and qos priorities simultaneously:
>
> parameters.encodings[0].priority = "high";
> Or specify each of them independently by providing a dictionary
> instead of an string:
>
> parameters.encodings[0].priority = {qos: "high", network: "low" };
> Just my two cents

Please read and comment on the proposal - I think I've shown how to get
both functionalities in the explainer, without breaking compatibility.

>
> Best regards
> Sergio
> On 28/11/2017 18:15, Harald Alvestrand wrote:
>> Picking up on a post-Singapore action item:
>>
>> I've written a very short (VERY short) spec for an extension to
>> webrtc-pc that allows one to control the setting of packet-level
>> priority separate from queue-management priority.
>>
>> This is at https://github.com/alvestrand/webrtc-dscp-exp
>>
>> Best starting point is probably the explainer:
>>
>> https://github.com/alvestrand/webrtc-dscp-exp/blob/master/explainer.md
>>
>>
>> The question now is - what now?
>>
>> Possible actions include adopting this in the WG, asking for adoption as
>> a WICG spec, or keeping it as an individual contribution.
>>
>>
>> What do people prefer?
>>
>>
>> Harald
>>
>>
>>
>
Received on Tuesday, 28 November 2017 17:43:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 28 November 2017 17:43:08 UTC