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

Justin Uberti <juberti@google.com> Wed, 31 July 2019 06:42 UTC

Return-Path: <juberti@google.com>
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 308EC120045 for <tsvwg@ietfa.amsl.com>; Tue, 30 Jul 2019 23:42:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 nAH-zYHSotq6 for <tsvwg@ietfa.amsl.com>; Tue, 30 Jul 2019 23:42:04 -0700 (PDT)
Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BDB3120047 for <tsvwg@ietf.org>; Tue, 30 Jul 2019 23:42:04 -0700 (PDT)
Received: by mail-vs1-xe2b.google.com with SMTP id a186so43829932vsd.7 for <tsvwg@ietf.org>; Tue, 30 Jul 2019 23:42:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JWRaSS9iFXzad3eElZT92r+y5aFOaRczc+9dsZFgWaQ=; b=BdkadCyp8+xcETBbwoWvH1FX+EqRg9BZQoUr5pOv/9WTmBjamuDbr+2fYFM6+LCEFb phpCZ8GZepBpeWy1EzSaDJClwPUIhkL+asoJxW8lHsLM5RFvvnFpOYTG55xenibN6ixJ PLfVot00ZpqVyalGwqbUdmwerAs620rW6gQbBIm+HAp2+HJ6RyYFnpycNaLk7wHItOBN N5izrIeBvEvkyiUtJaOA98M+SIigePQGPJ87pyWn0tFaH/xD1H3XU0VpyNC9cWeZ9hxP QdBQVKPBL2AsckTOTLMxWMzU/3vnKHABelOc/ot3zZkE2BqZYR4rglpzWTqieaxf6/xP Oeog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JWRaSS9iFXzad3eElZT92r+y5aFOaRczc+9dsZFgWaQ=; b=rdZf6rnOvd7epN0D/EXaT7rnP1bw9lwaBoZVy32FU5kgGmmXMk5AgNaTMXHrM11Fts RpOZIe67yOFHj+UBAv6hQk0I3YtkDUFfQW/BWcyNZRJnhoZX8XRCfes+X/ms/HGPrHi8 uM/iiXQLorT9RvyLvAyKOhj+ttwYDXLjDL9AadQ5ST2vN0RsG8vFSVpMxFJ0O8+PkblK gG+gu6H+v2ljiufZ6ZruvytFOKEa+QmkveGZ11TTMCE5KpJ3zySOGrz2YIHEUT5y8VvM 1F+TzInEBzzxIq9o+X3dJ2EXOMm+ZVsIgN9+05dP52mRPNFdy0umcEnosD6BeBemubpb iyEg==
X-Gm-Message-State: APjAAAVj7Yo288NQ++/OsWFOMY5Uz1StPewSQD3qK7ZYEMFPYV0wxKqf Bj0UIiutPD4TpTFXYTymN9vqcmzD12HPDCQY8Ijocw==
X-Google-Smtp-Source: APXvYqxasHA7f7EQoW/NyXXeemOvqw+ULagiV9PfPKMIMJ9+zNNqNncmfyV+gWCoQ24pwuBuGT2YiG0fe/V6P7BOf7c=
X-Received: by 2002:a67:e906:: with SMTP id c6mr28743491vso.82.1564555323108; Tue, 30 Jul 2019 23:42:03 -0700 (PDT)
MIME-Version: 1.0
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> <5D4135E9.90104@erg.abdn.ac.uk>
In-Reply-To: <5D4135E9.90104@erg.abdn.ac.uk>
From: Justin Uberti <juberti@google.com>
Date: Tue, 30 Jul 2019 23:41:50 -0700
Message-ID: <CAOJ7v-3ZDBniXeqQtmp_7FoZjo+v-dMAikQiRuNeQh5AWO_jJg@mail.gmail.com>
To: gorry@erg.abdn.ac.uk
Cc: Matthew Kaufman <mkaufman@bluejeans.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000445e4a058ef46cf9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/g6FJHn3wLaXw5q7KOa1q7ClErHE>
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:42:09 -0000

On Tue, Jul 30, 2019 at 11:32 PM Gorry Fairhurst <gorry@erg.abdn.ac.uk>
wrote:

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

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.

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