Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos

["Subha Dhesikan (sdhesika)" <[e-mail]>]

Wes,

In my view,  this draft important since it does provides guidance on a couple of fronts such as what the browser needs to do and what the application Javascript needs to do.  Also, it helps to clarify what inputs will be received from the application and what inputs are provided by the browser to the media engine. That is the key value of the draft. 

I understand that there will be an added complexity when the flow is no longer the traditional 5 tuple but a single flow can have multiple DSCP values. However, it is not a concept introduced by this draft. When applications have started allowing  multiplexing of different types of traffic into a single flow, the need has already been created. Not only in the webrtc space but also in the VDI space it is common to see flow that have multiplexed content. While we can restrict the QoS for multiplexed flows by saying only one DSCP allowed per flow, my experience has been that it is tremendously challenging for QoS to be relevant in such deployments.  

Having said the above, my draft does not either mandate a single or multiple DSCP for multiplexed flow.  One can always negotiate the lack of support for multiplexed flow in which case single flows will be used with one DSCP per flow.

Unfortunately, I will not be in Berlin. I am hoping that Cullen, Dan and you can chat some more if this continues to be an issue.

Regards,
Subha

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Wesley Eddy
Sent: Tuesday, July 09, 2013 7:57 PM
To: Cullen Jennings
Cc: DAN DRUTA; [e-mail]
Subject: Re: [tsvwg] draft-dhesikan-tsvwg-rtcweb-qos

On 7/8/2013 7:35 PM, Cullen Jennings wrote:
> 
> The draft-dhesikan-tsvwg-rtcweb-qos draft was discussed extensively when it was an individual draft then WG draft in another WG and I don't think there is much more to say about it. This is one of the normative dependencies of the webrtc work and that stuff is already getting implemented in browsers so I want to move this along in an expedient fashion. 


Without checking ... it makes no sense to me that there would be a normative dependency on this since it does not impact the interoperability or correctness of an implementation.

It's purely a performance enhancement, if/when it actually causes the intended things to happen in the network.

That said, I think the interesting facet of this document is that packets within the same flow (defined by 5-tuple of address-port pairs and protocol number) are receiving different codepoints, and the implications of that for a CC that may be on top of them need to be delved into.  There isn't really text or recommendations going into that, which seems to be the important part, as if you can figure that out, these mappings are the more obvious part.

So, I think it might make sense to do this, but the current document isn't addressing the implications or how this works in a bigger system sense, and I don't think the particular marking tables are the hard or important part.


--
Wes Eddy
MTI Systems