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

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

Subha,

<WG chair hat off>

I think some rewording is needed and reduction in scope.  My concern is two-fold:

1) RTC-Web documents should be focused on the browser and the browser behavior.
This sort of discussion of traffic conditioning at network boundaries that may
be well away from the browser seems peripheral.  Given the strong desire expressed
in both public and private by certain parties to get this draft done quickly,
expanding its scope to non-essential areas seems like a poor move.

2) RTC-Web traffic will not be the only user of these PHBs and DSCPs, and hence
probably should not be making recommendations on traffic conditioning in
general.  If there's a way to specifically identify RTC-Web flows (e.g., 
distinguish them from other uses of RTP), it could be appropriate to discuss
what a multi-field (MF) classifier and associated traffic conditioning
(see RFC 2475) should do to them at network boundaries, but there's no
requirement to deploy MF classifiers at network boundaries.

Unless there's an impact on how the browser should initially mark traffic, it may
be better to remove this text.

</WG chair hat off>

Thanks,
--David

> -----Original Message-----
> From: Subha Dhesikan (sdhesika) [mailto:[e-mail]]
> Sent: Tuesday, January 21, 2014 10:19 PM
> To: Black, David; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: RE: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos
> 
> David,
> 
> Please help me understand: Are you suggesting that the whole text should be
> removed or reworded to remove guidance and merely say that the DSCP values may
> have to be combined based on network policies where application classes are
> fewer.
> 
> Regards,
> Subha
> 
> -----Original Message-----
> From: Black, David [mailto:[e-mail]]
> Sent: Tuesday, January 21, 2014 10:59 AM
> To: Subha Dhesikan (sdhesika); [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Cc: Black, David
> Subject: RE: [tsvwg] comments on draft-dhesikan-tsvwg-rtcweb-qos
> 
> <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
> >
>