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?

On Tue, Jul 30, 2019 at 9:47 PM Matthew Kaufman <mkaufman@bluejeans.com>
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 <juberti@google.com>
> *Date: *Wednesday, July 31, 2019 at 10:08 AM
> *To: *Matthew Kaufman <mkaufman@bluejeans.com>
> *Cc: *"tsvwg@ietf.org" <tsvwg@ietf.org>, "rtcweb@ietf.org" <
> rtcweb@ietf.org>
> *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 <mkaufman@bluejeans.com>
> 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.
>
>
>
> 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=>
>
>
>
> 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
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> 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=>
>
>