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

["Black, David" <[e-mail]>]

<WG chair hat off>

> - Provided some guidance for networks with reduced number of DSCP classes.

That guidance would be (or would start with):

   If a packet enters a QoS domain that has no support for the above
   defined Data Types/Application classes, then the network node at the
   edge SHOULD map the DSCP value to one used by supported classes.
   Here are a couple of examples:

   o  If a QoS domain supports only one video class, then the packets
      from the two video classes SHOULD be remarked to use the same
      DSCP, either AF4 or AF3 whichever is supported.
   o  If a QoS domain supports a single class for all voice and video
      traffic, then the packets from all the video and voice classes
      SHOULD be combined and remarked to the single supported DSCP.

This draft may not be a good place for that - there are concerns well beyond
rtcweb that drive these decisions by network architects/operators.

</WG chair hat off>

Thanks,
--David

> -----Original Message-----
> From: tsvwg [mailto:[e-mail]] On Behalf Of Subha Dhesikan
> (sdhesika)
> Sent: Tuesday, January 21, 2014 12:57 PM
> To: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos
> 
> 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
>