Re: [tsvwg] [rtcweb] 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: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@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/tsvwg/QOjlOf8ArBkdmrR5VKRCluS3IBM>
Subject: Re: [tsvwg] [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-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=>
>