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

From: "Subha Dhesikan (sdhesika)" <[email-masked]>
Date: Tue, 21 Jan 2014 17:57:08 +0000

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:[email-masked]] On Behalf Of Subha Dhesikan (sdhesika)
Sent: Thursday, December 19, 2013 9:28 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
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:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, December 18, 2013 3:28 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
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

---

From: "Subha Dhesikan (sdhesika)" <[email-masked]>
Date: Wed, 22 Jan 2014 03:18:35 +0000

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:[email-masked]] 
Sent: Tuesday, January 21, 2014 10:59 AM
To: Subha Dhesikan (sdhesika); [email-masked]; [email-masked]; [email-masked]; [email-masked]
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

> From: tsvwg [mailto:[email-masked]] On Behalf Of Subha 
> Dhesikan
> (sdhesika)
> Sent: Tuesday, January 21, 2014 12:57 PM
> To: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> From: tsvwg [mailto:[email-masked]] On Behalf Of Subha 
> Dhesikan
> (sdhesika)
> > 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.
> >
> > 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.
> >
> > DiffServ markings sent by a consumer device. The draft doesn't 
> > mention that. Adding such a note may be useful.
> >
> 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.
> 
> > 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.

---

From: "Black, David" <[email-masked]>
Date: Tue, 21 Jan 2014 13:59:12 -0500

<WG chair hat off>

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

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

---

From: "Black, David" <[email-masked]>
Date: Wed, 22 Jan 2014 10:28:30 -0500

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

> From: Subha Dhesikan (sdhesika) [mailto:[email-masked]]
> Sent: Tuesday, January 21, 2014 10:19 PM
> To: Black, David; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> 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
>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 22 Jan 2014 13:27:39 -0800

> 1) RTC-Web documents should be focused on the browser and the browser

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

> > To: Subha Dhesikan (sdhesika); [email-masked];
> [email-masked];
> > > > within LANs, for home gateway internal classification and for Wifi.
> That's
> > fine with me.
> > > >
> > > > network devices apply proper markings as suggested by the authors,
> this
> > may help.
> > > >
> > >
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>