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

[Ted Hardie <[e-mail]>]

On Wed, Jan 22, 2014 at 7:28 AM, Black, David <[e-mail]> wrote:

> 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.
>

Just as a wordsmithing correction, we should say "WebRTC endpoints" rather
than browser, since mobile (or other) applications may use the WebRTC
framework without being a browser.  Though we could easily rat-hole on what
constitutes a browser, generalizing this to "WebRTC endpoint" seems to
avoid the issue.

regards,

Ted Hardie



> 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
> > >
> >
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>