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

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

A new draft of the QoS document for rtcweb has been posted with the edits suggested below. The edits are:
- Noted the trust issue and possibility of remarking at network edge
- Provided some guidance for networks with reduced number of DSCP classes.

 http://www.ietf.org/internet-drafts/draft-dhesikan-tsvwg-rtcweb-qos-04.txt

Regards,
Subha


-----Original Message-----
From: tsvwg [mailto:[e-mail]] On Behalf Of Subha Dhesikan (sdhesika)
Sent: Thursday, December 19, 2013 9:28 AM
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos

Thank you for your comments, Ruediger and Gorry.

Inline as SD:

-----Original Message-----
From: tsvwg [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Wednesday, December 18, 2013 3:28 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos

See a few thoughts in-line (with no chair-hat):

> Hi Gorry,
>
> my small contribution to discuss the TSVWG input:
>
> draft dhesikan -03 is a rather short document. It is now focused on IP 
> DSCP markings suggested for RTCweb traffic. I appreciate that the 3GPP 
> QCI related discussion has been removed.
>
> The authors of draft dhesikan prefer to support a wide set of DSCPs 
> and suggest to support different levels of priority. The introduction 
> seems to say, it is largely considered to be applied within LANs, for 
> home gateway internal classification and for Wifi. That's fine with me.
>
> In the case of traffic sent to a network provider broadband access 
> router / network gateway, I doubt that too many markings make sense.
> I'd expect the network provider routers or gateways not to trust 
> DiffServ markings sent by a consumer device. The draft doesn't mention 
> that. Adding such a note may be useful.
>
Personally I'd agree - it would be useful to describe this context

SD:  Sounds good. I will add a statement or two on lack of trust of client devices and the effect on DSCP marking. 

In addition, I am expecting there will be some work done on the authorization mechanisms for webrtc traffic that will allow some off-path authorization of DSCP for particular flows.

> As I'm known for simplistic approaches, my take is to mark traffic 
> sent by a home gateway to a provider policy point by two DSCPs only, 
> Best Effort and an AF PHB. I agree however with the authors, that a 
> Home Gateway could and should internally apply a much more fine 
> grained QoS differentiation for upstream traffic. If all home network 
> devices apply proper markings as suggested by the authors, this may help.
>

I think it would be useful to say that each DSCP by a single app require a way for the app or transport to know which work appropriately along that path. Especially when traffic is dynamically moved between different PHB groups.

The fact that many deployed networks support a small set of DSCPs is worth I think a mention. To me this has some implications, e.g. when the App sets EF or CS1 and networks supports just AF and BE - intended precedence would then rely upon correct treatment or re-marking. If this were not appropriate, then the loss will depend upon whether it was before or after the DSCPs were interpreted as intended.

SD: ack. Yes, it is possible to add an example or two on how the DSCPs defined in this document can be treated in a network that has only 2-4 PHBs.

> If there's interest to approach the 3GPP community for a discussion on 
> a useful relation between 3GPP QCIs and IP PHBs, I'd be happy to help.
> This should be documented in a separate draft, as I'd expect this 
> inter SDO work to consume a fair amount of time.
SD: I will also participate as needed. 

Regards,
Subha
>
> Regards and seasonal greetings,
>
> Ruediger
>
>
>
Gorry