Re: [rtcweb] [tsvwg] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Wed, 31 July 2019 06:32 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD40B120052; Tue, 30 Jul 2019 23:32:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkrIuKbMGNG0; Tue, 30 Jul 2019 23:32:18 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC6112004F; Tue, 30 Jul 2019 23:32:18 -0700 (PDT)
Received: from MacBook-Pro-5.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 8216B1B000FA; Wed, 31 Jul 2019 07:32:11 +0100 (BST)
Message-ID: <5D4135E9.90104@erg.abdn.ac.uk>
Date: Wed, 31 Jul 2019 07:32:09 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Justin Uberti <juberti=40google.com@dmarc.ietf.org>
CC: Matthew Kaufman <mkaufman@bluejeans.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <EA953E34-51FA-4B17-A0B2-6CF75146A754@contoso.com> <CAOJ7v-3tvxOiP073tE7iUPueZJYy+hSZnyGJznhMekShRbHg4A@mail.gmail.com> <64D66E22-E816-4AC7-8887-9CDC01A3252C@bluejeans.com> <CAOJ7v-2G+w0Luf7OF0xbf+rLOVRHa-QcbWXLmZ+_rLS9wnCA1w@mail.gmail.com> <D36DCE87-8A9E-4D3E-9241-3BA356D1ACFB@bluejeans.com> <CAOJ7v-2o95utN_89-8kDa1ySq3-=4TNfUh4tyyo_adxgorH9XQ@mail.gmail.com>
In-Reply-To: <CAOJ7v-2o95utN_89-8kDa1ySq3-=4TNfUh4tyyo_adxgorH9XQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/bLxq1qXVr28ptRzdF0z7FtX0vUs>
Subject: Re: [rtcweb] [tsvwg] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jul 2019 06:32:23 -0000
On 31/07/2019, 06:12, Justin Uberti wrote: > > > On Tue, Jul 30, 2019 at 10:10 PM Matthew Kaufman > <mkaufman@bluejeans.com <mailto:mkaufman@bluejeans.com>> 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. > > (Never mind that Windows has limitations on marking, which I’m > sure we’ve all dealt with) > > Matthew Kaufman > > *From: *Justin Uberti <juberti@google.com <mailto:juberti@google.com>> > *Date: *Wednesday, July 31, 2019 at 10:36 AM > *To: *Matthew Kaufman <mkaufman@bluejeans.com > <mailto:mkaufman@bluejeans.com>> > *Cc: *"tsvwg@ietf.org <mailto:tsvwg@ietf.org>" <tsvwg@ietf.org > <mailto:tsvwg@ietf.org>>, "rtcweb@ietf.org > <mailto:rtcweb@ietf.org>" <rtcweb@ietf.org <mailto:rtcweb@ietf.org>> > *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 > <mkaufman@bluejeans.com <mailto: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 > <mailto:juberti@google.com>> > *Date: *Wednesday, July 31, 2019 at 10:08 AM > *To: *Matthew Kaufman <mkaufman@bluejeans.com > <mailto:mkaufman@bluejeans.com>> > *Cc: *"tsvwg@ietf.org <mailto:tsvwg@ietf.org>" <tsvwg@ietf.org > <mailto:tsvwg@ietf.org>>, "rtcweb@ietf.org > <mailto:rtcweb@ietf.org>" <rtcweb@ietf.org > <mailto: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 <mailto: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 <mailto: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=> >
- [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos Matthew Kaufman
- Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcwe… Justin Uberti
- Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcwe… Matthew Kaufman
- Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcwe… Justin Uberti
- Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcwe… Matthew Kaufman
- Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcwe… Justin Uberti
- Re: [rtcweb] [tsvwg] STUN DSCP and draft-ietf-tsv… Gorry Fairhurst
- Re: [rtcweb] [tsvwg] STUN DSCP and draft-ietf-tsv… Justin Uberti
- Re: [rtcweb] [tsvwg] STUN DSCP and draft-ietf-tsv… Ruediger.Geib
- Re: [rtcweb] [tsvwg] STUN DSCP and draft-ietf-tsv… Mirja Kuehlewind
- Re: [rtcweb] [tsvwg] STUN DSCP and draft-ietf-tsv… Black, David
- Re: [rtcweb] [tsvwg] STUN DSCP and draft-ietf-tsv… Harald Alvestrand
- Re: [rtcweb] [tsvwg] STUN DSCP and draft-ietf-tsv… Justin Uberti