Subject: [rtcweb] diffserv marking for rtcwb data channel

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Fri, 24 Jul 2015 08:44:41 +0200

HI,

I don’t think that it makes much difference (though see further below…)
whether one use

different sctp associations for multiple data channels with different

diffserv code points or have this feature be built into SCTP.

The differences I can think of are:

·         end-point performance (only significant if cache and cpu
constrained)

·         flow control handling – can be both good and bad to have separate
receiver windows perhaps

I do question, however, whether it is a “good” choice to use the diffserv
marking and sctp association split for

prioritization of the traffic instead of SCTP scheduling differentiation
within one and the same association over a non-marked

or homogeneously marked network.

Especially the two have very different characteristics from a (coupled)
congestion control perspective (including loss recovery).

But if both possibilities go in, I suppose that we will learn much more
about this in the future.

But one should perhaps do well  to provide some starting ground rules for
when one or the other is considered

most appropriate to use – possible try to describe the conditions under
which one would like to use one or

the other.

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.

BR, Karen

---

From: <[email-masked]>
Date: Fri, 24 Jul 2015 10:00:07 +0200

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: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Fri, 24 Jul 2015 10:27:41 +0200

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]]
*Sent:* Friday, July 24, 2015 10:00 AM
*To:* [email-masked]
*Cc:* [email-masked]; [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

       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

conservative and hard to maintain. I wouldn’t expect full 5 tuple as basis
for a QoS

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: <[email-masked]>
Date: Fri, 24 Jul 2015 11:32:33 +0200

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]; [email-masked]; Michael Tuexen; [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.

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,

Regards,

Ruediger