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

From: Matthew Kaufman <[email-masked]>
Date: Wed, 31 Jul 2019 04:08:43 +0000

Was chasing down some webrtc rabbit holes today, and came across the following concern:

draft-ietf-tsvwg-rtcweb-qos has exactly zero language about how the STUN packets should be marked for ICE negotiation. The issue is mentioned in draft-ietf-rtcweb-stun-consent-freshness, but I believe that the rtcweb-qos document should be the reference to how an rtcweb transport author should be setting DiffServ markings.

Also, there was a great conversation on the topic back in 2014 that unfortunately seems to have petered out before a resolution to some obvious open issues: https://mailarchive.ietf.org/arch/browse/rtcweb/?gbt=1&index=HH0qztqt4UtfZdpuxHTVcg7hZdE

Would be great to finish the conversation before finalizing the specification for how to mark these.

Personally I’m in the “ICE is testing connectivity, so STUN must be marked exactly the same as corresponding media” camp.

Matthew Kaufman

---

From: Justin Uberti <[email-masked]>
Date: Tue, 30 Jul 2019 21:38:30 -0700

I had thought this was already covered in
https://tools.ietf.org/html/rfc5245#section-7.1.2.4, which basically says
exactly what you are asking for.

On Tue, Jul 30, 2019 at 9:09 PM Matthew Kaufman <[email-masked]>
wrote:

> draft-ietf-tsvwg-rtcweb-qos has exactly zero language about how the STUN
> packets should be marked for ICE negotiation. The issue is mentioned in
> draft-ietf-rtcweb-stun-consent-freshness, but I believe that the rtcweb-qos
> document should be the reference to how an rtcweb transport author should
> be setting DiffServ markings.
>
>
>
> Also, there was a great conversation on the topic back in 2014 that
> unfortunately seems to have petered out before a resolution to some obvious
> open issues:
> https://mailarchive.ietf.org/arch/browse/rtcweb/?gbt=1&index=HH0qztqt4UtfZdpuxHTVcg7hZdE
>
>
>
> Personally I’m in the “ICE is testing connectivity, so STUN must be marked
> exactly the same as corresponding media” camp.
>
>
>
> Matthew Kaufman
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 31 Jul 2019 04:47:30 +0000

IF one believes that none of the open issues mentioned in the email thread I sent are an issue, then sure, RFC5245 applies.

But even so, I would argue that draft-ietf-tsvwg-rtcweb-qos should say what to do and reference 5245.

Alternatively, one might believe that one or more of the issues are a real problem… in which case we should specify alternative behavior.

Matthew Kaufman

From: Justin Uberti <[email-masked]>
Date: Wednesday, July 31, 2019 at 10:08 AM
To: Matthew Kaufman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos

I had thought this was already covered in https://tools.ietf.org/html/rfc5245#section-7.1.2.4<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5245-23section-2D7.1.2.4&d=DwMFaQ&c=PpPcabknNF6XJFBaeGH06g&r=9ZdwibcaitRZyo80OngsIQIXTs5v-9PG8HT1YlIatVI&m=fbpMIVl4LuFN5soU2Avi1NbII--opolVHejelXn2svE&s=ltGEgbp10iUc1gBO_cimQvtZZ9HfiJOm_ysp3ZOo0eQ&e=>, which basically says exactly what you are asking for.

On Tue, Jul 30, 2019 at 9:09 PM Matthew Kaufman <[email-masked]<mailto:[email-masked]>> wrote:
Was chasing down some webrtc rabbit holes today, and came across the following concern:

Also, there was a great conversation on the topic back in 2014 that unfortunately seems to have petered out before a resolution to some obvious open issues: https://mailarchive.ietf.org/arch/browse/rtcweb/?gbt=1&index=HH0qztqt4UtfZdpuxHTVcg7hZdE<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_browse_rtcweb_-3Fgbt-3D1-26index-3DHH0qztqt4UtfZdpuxHTVcg7hZdE&d=DwMFaQ&c=PpPcabknNF6XJFBaeGH06g&r=9ZdwibcaitRZyo80OngsIQIXTs5v-9PG8HT1YlIatVI&m=fbpMIVl4LuFN5soU2Avi1NbII--opolVHejelXn2svE&s=FlrSPxMvUIrN-iqDsEmRI1U0URJnINsru1TEVWNMUBQ&e=>

Matthew Kaufman
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rtcweb&d=DwMFaQ&c=PpPcabknNF6XJFBaeGH06g&r=9ZdwibcaitRZyo80OngsIQIXTs5v-9PG8HT1YlIatVI&m=fbpMIVl4LuFN5soU2Avi1NbII--opolVHejelXn2svE&s=89GkSxwEhG63-il9an69COx4NNrA8nM3i4siRUHMFHM&e=>

---

From: Justin Uberti <[email-masked]>
Date: Tue, 30 Jul 2019 22:06:32 -0700

hmm, right. We have definitely observed that some networks will eat marked
traffic, so there needs to be some sort of trial exchange to ensure a given
marking will work.

Can you summarize the other issues you are concerned about?

On Tue, Jul 30, 2019 at 9:47 PM Matthew Kaufman <[email-masked]>
wrote:

> IF one believes that none of the open issues mentioned in the email thread
> I sent are an issue, then sure, RFC5245 applies.
>
>
>
> Alternatively, one might believe that one or more of the issues are a real
> problem… in which case we should specify alternative behavior.
>
>
>
> Matthew Kaufman
>
>
>
> *From: *Justin Uberti <[email-masked]>
> *Date: *Wednesday, July 31, 2019 at 10:08 AM
> *To: *Matthew Kaufman <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos
>
>
>
> https://tools.ietf.org/html/rfc5245#section-7.1.2.4
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5245-23section-2D7.1.2.4&d=DwMFaQ&c=PpPcabknNF6XJFBaeGH06g&r=9ZdwibcaitRZyo80OngsIQIXTs5v-9PG8HT1YlIatVI&m=fbpMIVl4LuFN5soU2Avi1NbII--opolVHejelXn2svE&s=ltGEgbp10iUc1gBO_cimQvtZZ9HfiJOm_ysp3ZOo0eQ&e=>,
> which basically says exactly what you are asking for.
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_browse_rtcweb_-3Fgbt-3D1-26index-3DHH0qztqt4UtfZdpuxHTVcg7hZdE&d=DwMFaQ&c=PpPcabknNF6XJFBaeGH06g&r=9ZdwibcaitRZyo80OngsIQIXTs5v-9PG8HT1YlIatVI&m=fbpMIVl4LuFN5soU2Avi1NbII--opolVHejelXn2svE&s=FlrSPxMvUIrN-iqDsEmRI1U0URJnINsru1TEVWNMUBQ&e=>
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rtcweb&d=DwMFaQ&c=PpPcabknNF6XJFBaeGH06g&r=9ZdwibcaitRZyo80OngsIQIXTs5v-9PG8HT1YlIatVI&m=fbpMIVl4LuFN5soU2Avi1NbII--opolVHejelXn2svE&s=89GkSxwEhG63-il9an69COx4NNrA8nM3i4siRUHMFHM&e=>
>
>

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 31 Jul 2019 05:09:59 +0000

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

The other is picking which DSCP value in the case where multiplexing is in use and you don’t know whether you’re audio-only or audio-plus-video or data-only at the time you do the ICE exchange.

(Never mind that Windows has limitations on marking, which I’m sure we’ve all dealt with)

Matthew Kaufman

Date: Wednesday, July 31, 2019 at 10:36 AM

hmm, right. We have definitely observed that some networks will eat marked traffic, so there needs to be some sort of trial exchange to ensure a given marking will work.

On Tue, Jul 30, 2019 at 9:47 PM Matthew Kaufman <[email-masked]<mailto:[email-masked]>> wrote:
IF one believes that none of the open issues mentioned in the email thread I sent are an issue, then sure, RFC5245 applies.

Matthew Kaufman

From: Justin Uberti <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 31, 2019 at 10:08 AM
To: Matthew Kaufman <[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: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos

Matthew Kaufman

---

From: Justin Uberti <[email-masked]>
Date: Tue, 30 Jul 2019 22:12:53 -0700

On Tue, Jul 30, 2019 at 10:10 PM Matthew Kaufman <[email-masked]>
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).
>

I lean towards 'work as often as possible', which suggests we probably need
both marked and unmarked ICE checks to determine whether we should mark
media traffic (and potentially multiple differently marked checks in the
mux case).

>
>
> The other is picking which DSCP value in the case where multiplexing is in
> use and you don’t know whether you’re audio-only or audio-plus-video or
> data-only at the time you do the ICE exchange.
>
>
>
> *Date: *Wednesday, July 31, 2019 at 10:36 AM

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 31 Jul 2019 07:32:09 +0100

On 31/07/2019, 06:12, Justin Uberti wrote:
>
>
> On Tue, Jul 30, 2019 at 10:10 PM Matthew Kaufman 
> <[email-masked] <mailto:[email-masked]>> 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.

Gorry

> I lean towards 'work as often as possible', which suggests we probably 
> need both marked and unmarked ICE checks to determine whether we 
> should mark media traffic (and potentially multiple differently marked 
> checks in the mux case).
>
>     The other is picking which DSCP value in the case where
>     multiplexing is in use and you don’t know whether you’re
>     audio-only or audio-plus-video or data-only at the time you do the
>     ICE exchange.
>
>     *From: *Justin Uberti <[email-masked] <mailto:[email-masked]>>
>     *To: *Matthew Kaufman <[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]>>
>     hmm, right. We have definitely observed that some networks will
>     eat marked traffic, so there needs to be some sort of trial
>     exchange to ensure a given marking will work.
>
>     On Tue, Jul 30, 2019 at 9:47 PM Matthew Kaufman
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         IF one believes that none of the open issues mentioned in the
>         email thread I sent are an issue, then sure, RFC5245 applies.
>
>         But even so, I would argue that draft-ietf-tsvwg-rtcweb-qos
>         should say what to do and reference 5245.
>
>         Alternatively, one might believe that one or more of the
>         issues are a real problem… in which case we should specify
>         alternative behavior.
>
>         Matthew Kaufman
>
>         *From: *Justin Uberti <[email-masked]
>         <mailto:[email-masked]>>
>         *To: *Matthew Kaufman <[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]>>
>         On Tue, Jul 30, 2019 at 9:09 PM Matthew Kaufman
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>             draft-ietf-tsvwg-rtcweb-qos has exactly zero language
>             about how the STUN packets should be marked for ICE
>             negotiation. The issue is mentioned in
>             draft-ietf-rtcweb-stun-consent-freshness, but I believe
>             that the rtcweb-qos document should be the reference to
>             how an rtcweb transport author should be setting DiffServ
>             markings.
>
>             Also, there was a great conversation on the topic back in
>             2014 that unfortunately seems to have petered out before a
>             resolution to some obvious open issues:
>             Would be great to finish the conversation before
>             finalizing the specification for how to mark these.
>
>             Personally I’m in the “ICE is testing connectivity, so
>             STUN must be marked exactly the same as corresponding
>             media” camp.
>
>             Matthew Kaufman
>
>             [email-masked] <mailto:[email-masked]>

---

From: Justin Uberti <[email-masked]>
Date: Tue, 30 Jul 2019 23:41:50 -0700

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

> >     *From: *Justin Uberti <[email-masked] <mailto:[email-masked]
> >>
> >         <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5245-23section-2D7.1.2.4&d=DwMFaQ&c=PpPcabknNF6XJFBaeGH06g&r=9ZdwibcaitRZyo80OngsIQIXTs5v-9PG8HT1YlIatVI&m=fbpMIVl4LuFN5soU2Avi1NbII--opolVHejelXn2svE&s=ltGEgbp10iUc1gBO_cimQvtZZ9HfiJOm_ysp3ZOo0eQ&e=
> >,
> >             <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_browse_rtcweb_-3Fgbt-3D1-26index-3DHH0qztqt4UtfZdpuxHTVcg7hZdE&d=DwMFaQ&c=PpPcabknNF6XJFBaeGH06g&r=9ZdwibcaitRZyo80OngsIQIXTs5v-9PG8HT1YlIatVI&m=fbpMIVl4LuFN5soU2Avi1NbII--opolVHejelXn2svE&s=FlrSPxMvUIrN-iqDsEmRI1U0URJnINsru1TEVWNMUBQ&e=
> >
> >
> >             <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rtcweb&d=DwMFaQ&c=PpPcabknNF6XJFBaeGH06g&r=9ZdwibcaitRZyo80OngsIQIXTs5v-9PG8HT1YlIatVI&m=fbpMIVl4LuFN5soU2Avi1NbII--opolVHejelXn2svE&s=89GkSxwEhG63-il9an69COx4NNrA8nM3i4siRUHMFHM&e=
> >
> >
>
>

---

From: <[email-masked]>
Date: Wed, 31 Jul 2019 07:18:59 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:
On 31/07/2019, 06:12, Justin Uberti wrote:
> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>

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.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 31 Jul 2019 09:21:57 +0000

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 <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Wednesday, 31. July 2019 at 09:19
To: "juberti=[email-masked]" <juberti=[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [tsvwg] [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos

Regards, Ruediger

---

From: "Black, David" <[email-masked]>
Date: Wed, 31 Jul 2019 13:34:23 +0000

+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 <[email-masked]> On Behalf Of Mirja Kuehlewind
Sent: Wednesday, July 31, 2019 5:22 AM
To: [email-masked]; juberti=[email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [tsvwg] [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos

[EXTERNAL EMAIL]

Mirja

From: tsvwg <[email-masked]<mailto:[email-masked]>> on behalf of "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 31. July 2019 at 09:19
To: "juberti=[email-masked]<mailto:juberti=[email-masked]>" <juberti=[email-masked]<mailto:juberti=[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] [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos

Regards, Ruediger

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 31 Jul 2019 16:07:43 +0200

draft-ietf-tsvwg-rtcweb-qos is out of scope for this working group, but
didn't we cover this ground extensively in draft-ietf-rtcweb-transport?

Namely (from -17):

4.2.  Usage of Quality of Service - DSCP and Multiplexing

   When the packet is sent, the network will make decisions about
   queueing and/or discarding the packet that can affect the quality of
   the communication.  The sender can attempt to set the DSCP field of
   the packet to influence these decisions.

   Implementations SHOULD attempt to set QoS on the packets sent,
   according to the guidelines in [I-D.ietf-tsvwg-rtcweb-qos].  It is
   appropriate to depart from this recommendation when running on
   platforms where QoS marking is not implemented.

   The implementation MAY turn off use of DSCP markings if it detects
   symptoms of unexpected behaviour like priority inversion or blocking
   of packets with certain DSCP markings.  Some examples of such
   behaviors are described in [ANRW16].  The detection of these
   conditions is implementation dependent.

   A particularly hard problem is when one media transport uses multiple
   DSCP code points, where one may be blocked and another may be
   allowed.  This is allowed even within a single media flow for video
   in [I-D.ietf-tsvwg-rtcweb-qos].  Implementations need to diagnose
   this scenario; one possible implementation is to send initial ICE
   probes with DSCP 0, and send ICE probes on all the DSCP code points
   that are intended to be used once a candidate pair has been selected.
   If one or more of the DSCP-marked probes fail, the sender will switch
   the media type to using DSCP 0.  This can be carried out
   simultaneously with the initial media traffic; on failure, the
   initial data may need to be resent.  This switch will of course
   invalidate any congestion information gathered up to that point.

   Failures can also start happening during the lifetime of the call;
   this case is expected to be rarer, and can be handled by the normal
   mechanisms for transport failure, which may involve an ICE restart.

   Note that when a DSCP code point causes non-delivery, one has to
   switch the whole media flow to DSCP 0, since all traffic for a single
   media flow needs to be on the same queue for congestion control
   purposes.  Other flows on the same transport, using different DSCP
   code points, don't need to change.

   All packets carrying data from the SCTP association supporting the
   data channels MUST use a single DSCP code point.  The code point used
   SHOULD be that recommended by [I-D.ietf-tsvwg-rtcweb-qos] for the
   highest priority data channel carried.  Note that this means that all
   data packets, no matter what their relative priority is, will be
   treated the same by the network.

   All packets on one TCP connection, no matter what it carries, MUST
   use a single DSCP code point.

   More advice on the use of DSCP code points with RTP and on the
   relationship between DSCP and congestion control is given in
   [RFC7657].

Den 31.07.2019 07:12, skrev Justin Uberti:
> 
> 
> On Tue, Jul 30, 2019 at 10:10 PM Matthew Kaufman <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     to what one should do in this case (follow network admin desires vs.
>     work as often as possible).
> 
> 
> need both marked and unmarked ICE checks to determine whether we should
> mark media traffic (and potentially multiple differently marked checks
> in the mux case). 
> 
>     ____
> 
>     __ __
> 
>     The other is picking which DSCP value in the case where multiplexing
>     is in use and you don’t know whether you’re audio-only or
>     audio-plus-video or data-only at the time you do the ICE exchange.____
> 
>     __ __
> 
>     (Never mind that Windows has limitations on marking, which I’m sure
>     we’ve all dealt with)____
> 
>     __ __
> 
>     Matthew Kaufman____
> 
>     __ __
> 
>     <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>"
>     <[email-masked] <mailto:[email-masked]>>
>     *Subject: *Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos____
> 
>     __ __
> 
>     hmm, right. We have definitely observed that some networks will eat
>     marked traffic, so there needs to be some sort of trial exchange to
>     ensure a given marking will work.  ____
> 
>     __ __
> 
>     Can you summarize the other issues you are concerned about? ____
> 
>     __ __
> 
>     <[email-masked] <mailto:[email-masked]>> wrote:____
> 
>         email thread I sent are an issue, then sure, RFC5245 applies.____
> 
>          ____
> 
>         should say what to do and reference 5245.____
> 
>          ____
> 
>         Alternatively, one might believe that one or more of the issues
>         are a real problem… in which case we should specify alternative
>         behavior.____
> 
>          ____
> 
>         Matthew Kaufman____
> 
>          ____
> 
>         *Subject: *Re: [rtcweb] STUN DSCP and
>         draft-ietf-tsvwg-rtcweb-qos____
> 
>          ____
> 
>         I had thought this was already covered
>         in https://tools.ietf.org/html/rfc5245#section-7.1.2.4
>         which basically says exactly what you are asking for.____
> 
>          ____
> 
>         <[email-masked] <mailto:[email-masked]>> wrote:____
> 
>             Was chasing down some webrtc rabbit holes today, and came
>             across the following concern:____
> 
>              ____
> 
>             draft-ietf-tsvwg-rtcweb-qos has exactly zero language about
>             how the STUN packets should be marked for ICE negotiation.
>             The issue is mentioned in
>             draft-ietf-rtcweb-stun-consent-freshness, but I believe that
>             the rtcweb-qos document should be the reference to how an
>             rtcweb transport author should be setting DiffServ markings.____
> 
>              ____
> 
>             <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_browse_rtcweb_-3Fgbt-3D1-26index-3DHH0qztqt4UtfZdpuxHTVcg7hZdE&d=DwMFaQ&c=PpPcabknNF6XJFBaeGH06g&r=9ZdwibcaitRZyo80OngsIQIXTs5v-9PG8HT1YlIatVI&m=fbpMIVl4LuFN5soU2Avi1NbII--opolVHejelXn2svE&s=FlrSPxMvUIrN-iqDsEmRI1U0URJnINsru1TEVWNMUBQ&e=>____
> 
>              ____
> 
>             Would be great to finish the conversation before finalizing
>             the specification for how to mark these.____
> 
>              ____
> 
>             Personally I’m in the “ICE is testing connectivity, so STUN
>             must be marked exactly the same as corresponding media”
>             camp.____
> 
>              ____
> 
>             Matthew Kaufman____
> 
>             <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rtcweb&d=DwMFaQ&c=PpPcabknNF6XJFBaeGH06g&r=9ZdwibcaitRZyo80OngsIQIXTs5v-9PG8HT1YlIatVI&m=fbpMIVl4LuFN5soU2Avi1NbII--opolVHejelXn2svE&s=89GkSxwEhG63-il9an69COx4NNrA8nM3i4siRUHMFHM&e=>____
>

---

From: Justin Uberti <[email-masked]>
Date: Wed, 31 Jul 2019 16:21:09 -0700

Great, glad that we've already got this speced. Thanks Harald.