Subject: Re: [rtcweb] [tsvwg] diffserv marking for rtcweb data channel

From: "Black, David" <[email-masked]>
Date: Fri, 24 Jul 2015 12:29:04 +0000

<WG chair hat OFF>

> All DSCPs, which have not been negotiated between access and interconnection are possibly bleached, especially if a network
> provider operates QoS within the network.

“possibly” -> “probably” -> “almost certainly” depending on the network (YMMV).

> I’d like to read a little more about how WEBrtc figures out which QoS resources are configured and which of these are available
> for such a flow at an access when required. How and where are the resources consumed by each WERrtc PHB controlled and
> how are these aligned with the QoS resources consumed by other services?

The short Web RTC answer to all of the above “it doesn’t do that”.  The DSCPs are in effect QoS service requests that the various networks involved may deal with as they wish.  Bleaching is one possibility (in effect an “I don’t do that” response to the request).  Even in that case, there may be value in DSCP usage for forwarding by equipment between the browser and the interface to the ISP’s network (e.g., residential router/NAT/AP box).

In spite of all of the above, I have been told of good experiences with use of CS2 for gaming and CS1 for lower effort (less than best effort), plus EF use for gaming was mentioned in the tsvwg meeting yesterday.

This is not the first time I’ve heard a request for a “what QoS services are available via which DSCPs?” interface/protocol.  I don’t know of one, and I’m not sure how to incentivize deployment if we designed one.

What is likely to happen is that if certain types of traffic favor specific DSCPs, then operators who want to improve the user experience of those who send/receive such traffic may put in QoS mechanisms for such traffic keyed by those DSCPs at network ingress.  OTOH, a “tragedy of the commons” is possible here, e.g., the story in tsvwg about how a lot of non-voice traffic showing up marked as if it were voice resulted in the network operator removing that special treatment of (residential, I presume) voice traffic.

</WG chair hat OFF>

Thanks,
--David

From: tsvwg [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, July 24, 2015 5:33 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [tsvwg] diffserv marking for rtcwb data channel

Hi Karen,

QoS  needs to be commercially negotiated at interconnection. If QoS should be available at a consumer access, the consumer division of a company must be involved in addition as well as the technical staff setting up and maintaining technical configurations. 11 PHBs for a single consumer service are a challenging requirement.

All DSCPs, which have not been negotiated between access and interconnection are possibly bleached, especially if a network provider operates QoS within the network.

QoS to me means overprovisioning to ensure transport free of congestion. If I see 11 PHBs for a single flow, I’m not sure if this assumes more than CoS (drop me last). I’d like to read a little more about how WEBrtc figures out which QoS resources are configured and which of these are available for such a flow at an access when required. How and where are the resources consumed by each WERrtc PHB controlled and how are these aligned with the QoS resources consumed by other services?

Regards,

Ruediger

Von: Karen Elisabeth Egede Nielsen [mailto:[email-masked]]
Gesendet: Freitag, 24. Juli 2015 10:28
An: Geib, Rüdiger
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Michael Tuexen; [email-masked]<mailto:[email-masked]>
Betreff: RE: [tsvwg] diffserv marking for rtcwb data channel

Hi Ruediger,

Thanks a lot.

So I think that you’re saying that even if one made sure that different diff serv markings were
split on different 5-tuples, this setting likely would be bleached at the network.

Is that correctly understood ?

If so, then (it sounds to me – not knowing too much about this) that from a coupling congestion control perspective it
would be preferable to  use SCTP scheduling prioritization (within one and the same association) for fine granular differentiation in between
multiple data channels in between the same end-points rather than differentiation by means of diff serv marking.

When/if one get a more consistent and forceful ECN operation in AQMs and SCTP end-points, perhaps the coupling congestion
principles achieved by means of sctp stream scheduling get to be less important.
On the other hand, again as said before, having the one and the same, or multiple, flow control (receiver buffer) contexts may be
a strength (simplicity) or a weakness.

BR, Karen

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, July 24, 2015 10:00 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: AW: [tsvwg] diffserv marking for rtcwb data channel

Karen,

      Finally there was a comment at the tsvwg meeting that the same 5-tuple with
       different diffserv markings would not get through the network – if that generally
       is correct,  then the solution is very easy: one MUST use different associations to
       get port (5-tuple) differentiation.
       I think that if this is correct, one also wants to ask what happens if the diffserv is
       changed for the same 5-tuple – i.e., is the network robust to this change even if
       it is not robust to concurrent usage of different markings for the same 5-tuple.

Talking about the policies of the company I work for only:

Possibilities to enforce QoS policies at a provider BRAS or BNG terminating wired
consumer accesses are limited. QoS policies based on full 5 tuple are very
conservative and hard to maintain. I wouldn’t expect full 5 tuple as basis for a QoS
policy then. Trust in the correct information on which a BRAS/BNG can
base QoS classification is an important issue. In any case, I’d not expect
more than one DSCP is assigned based on such a policy for the time
being. I’m not aware of any actual requirement to support e.g. an AFn
class by all three PHBs.

At interconnection points, any unexpected DSCP is bleached. This must
be done to protect backbone QoS production. QoS transport can be
negotiated for a set of defined DSCPs.

A study of the EU found DPI to be more common in wireless communication than in wired communication. I’d not expect the QoS policies in that area to be more liberal than for fixed access networks for the time being.

Regards,

Ruediger

---

From: <[email-masked]>
Date: Sat, 25 Jul 2015 06:01:09 +0000

Sometimes legislation prohibits the QoS model over open internet, all traffic must be treated the same.

A VPN may be a solution, based on a SPs services model like Voice. Setting up a VPN on the fly once the connection is established may suit the needs of a developer.

Richard

Op 24 jul. 2015 om 14:29 heeft Black, David <[email-masked]<mailto:[email-masked]>> het volgende geschreven:

<WG chair hat OFF>

</WG chair hat OFF>

Thanks,
--David

From: tsvwg [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, July 24, 2015 5:33 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [tsvwg] diffserv marking for rtcwb data channel

Hi Karen,

Regards,

Ruediger

Hi Ruediger,

Thanks a lot.

BR, Karen

Karen,

Regards,

Ruediger

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Göran Eriksson AP <[email-masked]>
Date: Sat, 25 Jul 2015 13:56:27 +0000

>A VPN may be a solution, based on a SPs services model like Voice.
>Setting up a VPN on the fly once the connection is established may suit
>the needs of a developer.

You mean a “specialised service” in the EU net neutrality terminology?

A “VPN” can have many shapes and forms- a closed user group and HTTPS
would be sufficient, right?

Or?

>
>
>Richard
>
>
>Op 24 jul. 2015 om 14:29 heeft Black, David <[email-masked]> het
>volgende geschreven:
>
>
>
><WG chair hat OFF>
> 
>>
>All DSCPs, which have not been negotiated between access and
>interconnection are possibly bleached, especially if a network
>> I’d like to read a little more about how WEBrtc figures out which QoS
>>resources are configured and which of these are available
>> for such a flow at an access when required. How and where are the
>>resources consumed by each WERrtc PHB controlled and
>The short Web RTC answer to all of the above “it doesn’t do that”.  The
>DSCPs are in effect QoS service requests that the various networks
>involved may deal with as they
> wish.  Bleaching is one possibility (in effect an “I don’t do that”
>response to the request).  Even in that case, there may be value in DSCP
>usage for forwarding by equipment between the browser and the interface
>to the ISP’s network (e.g., residential router/NAT/AP
> box).
> 
>In spite of all of the above, I have been told of good experiences with
>use of CS2 for gaming and CS1 for lower effort (less than best effort),
>plus EF use for gaming
> was mentioned in the tsvwg meeting yesterday.
> 
>This is not the first time I’ve heard a request for a “what QoS services
>are available via which DSCPs?” interface/protocol.  I don’t know of one,
>and I’m not sure how
> to incentivize deployment if we designed one.
> 
>What is likely to happen is that if certain types of traffic favor
>specific DSCPs, then operators who want to improve the user experience of
>those who send/receive such
> traffic may put in QoS mechanisms for such traffic keyed by those DSCPs
>at network ingress.  OTOH, a “tragedy of the commons” is possible here,
>e.g., the story in tsvwg about how a lot of non-voice traffic showing up
>marked as if it were voice resulted in
> the network operator removing that special treatment of (residential, I
>presume) voice traffic.
> 
></WG chair hat OFF>
> 
>Thanks,
>--David
>
>
> 
>Cc: [email-masked];
>[email-masked]; 
>[email-masked] <mailto:[email-masked]>; [email-masked]
>QoS  needs to be commercially negotiated at interconnection. If QoS
>should be available at a consumer access, the consumer division of a
>company must be involved in addition as well as the technical staff
>setting
> up and maintaining technical configurations. 11 PHBs for a single
>consumer service are a challenging requirement.
> 
>All DSCPs, which have not been negotiated between access and
>interconnection are possibly bleached, especially if a network provider
>operates QoS within the network.
> 
>QoS to me means overprovisioning to ensure transport free of congestion.
>If I see 11 PHBs for a single flow, I’m not sure if this assumes more
>than CoS (drop me last). I’d like to read a little more about how
> WEBrtc figures out which QoS resources are configured and which of these
>are available for such a flow at an access when required. How and where
>are the resources consumed by each WERrtc PHB controlled and how are
>these aligned with the QoS resources consumed
> by other services?
> 
>Regards,
> 
>Ruediger
> 
>Cc: [email-masked];
>[email-masked] <mailto:[email-masked]>; Michael Tuexen; [email-masked]
>If so, then (it sounds to me – not knowing too much about this) that from
>a coupling congestion control perspective it
>
>would be preferable to  use SCTP scheduling prioritization (within one
>and the same association) for fine granular differentiation in between
>multiple data channels in between the same end-points rather than
>differentiation by means of diff serv marking.
> 
>When/if one get a more consistent and forceful ECN operation in AQMs and
>SCTP end-points, perhaps the coupling congestion
>On the other hand, again as said before, having the one and the same, or
>multiple, flow control (receiver buffer) contexts may be
>From:[email-masked] [mailto:[email-masked]]
>
>Cc: [email-masked];
>[email-masked] <mailto:[email-masked]>
>       different diffserv markings would not getthrough the network – if
>that generally 
>A study of the EU found DPI to be more common in wireless communication
>than in wired communication. I’d not expect the QoS policies in that area
>to be more liberal than for fixed access networks for the time
> being.
> 
>Regards,
> 
>Ruediger
> 
> 
> 
> 
>
>
>
>
>
>
>
>[email-masked]

---

From: <[email-masked]>
Date: Sat, 25 Jul 2015 17:16:13 +0000

> Op 25 jul. 2015 om 15:56 heeft Göran Eriksson AP <[email-masked]> het volgende geschreven:
> 
> 
> 
Indeed Net neutrality. 

> would be sufficient, right?
Something like bandwith reservaties: a temporarily tunnel to the centralized WebRTC server. Especially when using Voice and video.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 26 Jul 2015 07:57:50 +1200

> Sometimes legislation prohibits the QoS model over open internet, all traffic must be treated the same.

That is a problem for operators (and their lawyers). Actually I don't think that
either the EU regulations or the FCC rules prevent diffserv, as long as it isn't
used to discriminate against individual content providers. But as far as the IETF
is concerned, I believe we should ignore this completely. It's our job to define
technical methods to support QoS. It's not our job to decide who uses those methods.

   Brian

---

From: <[email-masked]>
Date: Mon, 27 Jul 2015 09:46:25 +0200

Richard, David,

on the last mile of a consumer access, Deutsche Telekom operates QoS. To produce QoS with flows having a high bandwidth as compared to the available resources of a class, admission control is required. That means control plane interaction with a service platform for all streams consuming QoS resources. This includes awareness of the access resources available per QoS class.

QoS interconnection with Deutsche Telekom's Voice platform is offered and operational. A VPN is used. Available PHBs and DSCPs are specified. Also the per flow signaling and payload properties are specified to some extent.

A VPN or an outer tunnel CoS / inner tunnel CoS scheme is useful if

-          no admission control or "live and let live" cooperation respectively between flows requesting QoS support in the last mile is intended.

-          the outer tunnel QoS may be Best Effort or another CoS like solution (a don't drop me first, but drop me before any QoS traffic gets dropped approach).

-          Then the inner tunnel can carry any DSCP desired and the outer tunnel may consist of one or two markings. The latter may have a chance to be carried end-to-end.

Another option may be to mark admission controlled traffic by DSCP a and produce WebRTC with DSCP b and c in the  same queue, however making sure that during congestion in that class all traffic without admission control (WebRTC)  gets dropped before traffic with admission control is dropped.

Regards,

Ruediger

Von: [email-masked] [mailto:[email-masked]]
Gesendet: Samstag, 25. Juli 2015 08:01
An: [email-masked]
Cc: Geib, Rüdiger; [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [rtcweb] [tsvwg] diffserv marking for rtcweb data channel

Richard

> provider operates QoS within the network.

"possibly" -> "probably" -> "almost certainly" depending on the network (YMMV).

> I'd like to read a little more about how WEBrtc figures out which QoS resources are configured and which of these are available

The short Web RTC answer to all of the above "it doesn't do that".  The DSCPs are in effect QoS service requests that the various networks involved may deal with as they wish.  Bleaching is one possibility (in effect an "I don't do that" response to the request).  Even in that case, there may be value in DSCP usage for forwarding by equipment between the browser and the interface to the ISP's network (e.g., residential router/NAT/AP box).

This is not the first time I've heard a request for a "what QoS services are available via which DSCPs?" interface/protocol.  I don't know of one, and I'm not sure how to incentivize deployment if we designed one.

What is likely to happen is that if certain types of traffic favor specific DSCPs, then operators who want to improve the user experience of those who send/receive such traffic may put in QoS mechanisms for such traffic keyed by those DSCPs at network ingress.  OTOH, a "tragedy of the commons" is possible here, e.g., the story in tsvwg about how a lot of non-voice traffic showing up marked as if it were voice resulted in the network operator removing that special treatment of (residential, I presume) voice traffic.

</WG chair hat OFF>

Thanks,
--David

Hi Karen,

QoS to me means overprovisioning to ensure transport free of congestion. If I see 11 PHBs for a single flow, I'm not sure if this assumes more than CoS (drop me last). I'd like to read a little more about how WEBrtc figures out which QoS resources are configured and which of these are available for such a flow at an access when required. How and where are the resources consumed by each WERrtc PHB controlled and how are these aligned with the QoS resources consumed by other services?

Regards,

Ruediger

Hi Ruediger,

Thanks a lot.

So I think that you're saying that even if one made sure that different diff serv markings were
split on different 5-tuples, this setting likely would be bleached at the network.

If so, then (it sounds to me - not knowing too much about this) that from a coupling congestion control perspective it
would be preferable to  use SCTP scheduling prioritization (within one and the same association) for fine granular differentiation in between
multiple data channels in between the same end-points rather than differentiation by means of diff serv marking.

BR, Karen

Karen,

      Finally there was a comment at the tsvwg meeting that the same 5-tuple with
       different diffserv markings would not get through the network - if that generally
       is correct,  then the solution is very easy: one MUST use different associations to
       get port (5-tuple) differentiation.
       I think that if this is correct, one also wants to ask what happens if the diffserv is
       changed for the same 5-tuple - i.e., is the network robust to this change even if
       it is not robust to concurrent usage of different markings for the same 5-tuple.

Possibilities to enforce QoS policies at a provider BRAS or BNG terminating wired
consumer accesses are limited. QoS policies based on full 5 tuple are very
conservative and hard to maintain. I wouldn't expect full 5 tuple as basis for a QoS
policy then. Trust in the correct information on which a BRAS/BNG can
base QoS classification is an important issue. In any case, I'd not expect
more than one DSCP is assigned based on such a policy for the time
being. I'm not aware of any actual requirement to support e.g. an AFn
class by all three PHBs.

A study of the EU found DPI to be more common in wireless communication than in wired communication. I'd not expect the QoS policies in that area to be more liberal than for fixed access networks for the time being.

Regards,

Ruediger

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Jul 2015 23:48:38 +1200

Ruediger brings out an important point.

Diffserv can only work properly if there is admission control
for every traffic class that claims to offer definite guarantees.

That isn't because the people who defined diffserv were trying
to be annoying. It's because of the physics and mathematics of
queuing systems.

Regards
   Brian