Re: [rtcweb] [tsvwg] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos

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

+1 on Mirja’s remarks.  There are DSCP-sensitive routing technologies, and DetNet (Deterministic Networking) will use the DSCP as part of selecting the data plane at DetNet network nodes, so use of the same DSCP as the traffic to be sent helps ensure that the established connectivity actually works for the traffic to be sent … which is at least convenient ;-).

Next concern – which DSCPs?  There are a lot of DSCPs listed in draft-ietf-tsvwg-rtcweb-qos.  Suggested algorithm to select initial DSCP:

  1.  pick highest row in table that will be used in the WebRTC session (e.g., select Interactive Video over Non-Interactive Video);
  2.  select rightmost cell in that row that will be used (e.g., select High over Medium); and
  3.  if that cell contains two AF DSCPs, use the one with the better drop precedence (e.g., select AF41 over AF42).

Thanks, --David

From: tsvwg <[e-mail]> On Behalf Of Mirja Kuehlewind
Sent: Wednesday, July 31, 2019 5:22 AM
To: [e-mail]; juberti=[e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [tsvwg] [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos


[EXTERNAL EMAIL]
Yes, in measurements we usually see bleaching (not dropping). So it should be tested with the DSCP that is supposed to be used for the webrtc traffic and only tested without DSCP if connectivity for the case with DSCP was not successful.

The case Gorry mentioned, where some DSCP are rate-limited, is a problem but it’s not ICE’s problem (where the C stands for Connectivity).

Mirja



From: tsvwg <[e-mail]<mailto:[e-mail]>> on behalf of "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 31. July 2019 at 09:19
To: "juberti=[e-mail]<mailto:juberti=[e-mail]>" <juberti=[e-mail]<mailto:juberti=[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [tsvwg] [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos

The conservative approach is to mark traffic by the default DSCP, especially if there’s no QoS SLA between interconnected providers. I’m not sure how many networks drop traffic with unknown DSCPs. If the solution to this issue is to send traffic with a set of DSCPs to figure out what’s passing, the application should also be able to deal with remarked traffic (which I assume to be a network behavior to be expected).

Regards, Ruediger

On Tue, Jul 30, 2019 at 11:32 PM Gorry Fairhurst <[e-mail]<mailto:[e-mail]>> wrote:
On 31/07/2019, 06:12, Justin Uberti wrote:
>
>
> On Tue, Jul 30, 2019 at 10:10 PM Matthew Kaufman
> <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>> wrote:
>
>     I noted two of particular interest… one is the “network eats
>     DSCP-marked but allows non-marked” case. Arguments go both ways as
>     to what one should do in this case (follow network admin desires
>     vs. work as often as possible).
>
>
Is that a real observed case - that all traffic that sets a specific
DSCP is lost, rather than re-marked?

- There's also an obvious case where a specific DSCP is conditioned
(e.g. rate-limited), which means some packets traverse the path, but a
full media flow will not. However, not sure that observation helps at all.

I can't speak for others, but our experience with deploying DSCP en masse is that there are enough cases where dropping happens to outweigh the prioritization benefits.