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

[Matthew Kaufman <[e-mail]>]

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

From: Justin Uberti <[e-mail]>
Date: Wednesday, July 31, 2019 at 10:36 AM
To: Matthew Kaufman <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
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?

On Tue, Jul 30, 2019 at 9:47 PM Matthew Kaufman <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, July 31, 2019 at 10:08 AM
To: Matthew Kaufman <[e-mail]<mailto:[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: [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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
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=>