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

Justin Uberti <juberti@google.com> Wed, 31 July 2019 05:13 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 04145120075 for <tsvwg@ietfa.amsl.com>; Tue, 30 Jul 2019 22:13:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.4
X-Spam-Level:
X-Spam-Status: No, score=-17.4 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, HTTPS_HTTP_MISMATCH=0.1, 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=ham 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 3PBtct70rpAy for <tsvwg@ietfa.amsl.com>; Tue, 30 Jul 2019 22:13:06 -0700 (PDT)
Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 98062120019 for <tsvwg@ietf.org>; Tue, 30 Jul 2019 22:13:06 -0700 (PDT)
Received: by mail-vs1-xe2f.google.com with SMTP id m23so45331721vso.1 for <tsvwg@ietf.org>; Tue, 30 Jul 2019 22:13:06 -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=EOMIYR1GEwP4AIrOdfRbesZqnZKtwBeUyS7FK79BnXs=; b=j4cptWVK+iXZ7/4Rg6ared26JYfT1o08LD/kwnbxwU7w8HadmMfjBoMe4lUZeCt9as AA0v5QGhHdTMSSieP3c4/0mkfkrWFMSSqmQvWYT3cwVdIsDY+P3SYx+FJJQrX+eK/Xx9 mGBUnvjXVccq7IiJEnF2eubHA18T3w92Ei8A53hYIIKUQ16onrHmMOukUmSCtV4N6ULF R1NQXKpR16SUZ8N+Eq4/eZWFHoFbg8W1ZsnAtJVjvDU4N6smKsIsajgPAtQ15SaAvz/U 56Y+MOokikx8DI5a35gYUZD3l3LDczaVl8k3205K/y5MHMUBoyNU2qcMW0uHFP4IvZYB mPow==
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=EOMIYR1GEwP4AIrOdfRbesZqnZKtwBeUyS7FK79BnXs=; b=ew3XVr2SsL/vt8TsXtrPM9xCpilqhB7PUSp6nTvU4QAlLsyA3OZT2IIQNIi1134X1D 8H8Y9pRoF2sXpE8dAieN/rdugcmPUXDvLQOef0IUT4R/mBnqFU2RqxMlnkJAgOelKUKO WAkAfd80Dq2p1womVSKD5xDzGHruHkwNRflOLruGDeAOEvRA5+SQn4QY1lZlgDwPt5Zk 77bUC3Rkt4LJFnCHcLjiA8UBccIYc4LaKjO7F7OF28BAfwHLSgKX99kpZ50Swk/YM+1w VEcio1uIz63uve9vZEW5orSbYyJiucVnCAOKF8ze4rLUWcCHGfBMgNheG13XMwsebq06 UGeA==
X-Gm-Message-State: APjAAAUpAhwGZV8RlIk3B24rwRaBuR3P5g7fwdYnP7YBc0QsPKHGWK18 RVnqRpMUBfK17GrOUv3zclu5H+lyareksRltQi2zjw==
X-Google-Smtp-Source: APXvYqymAzL8xRvLWzDbddYyN/Fp9k5gngfuyt4SoklrFoXjd5keuUP15aZ8XJ/TxuJJ4GybD4SPdkq8pGfb/wGgG3M=
X-Received: by 2002:a67:e906:: with SMTP id c6mr28576056vso.82.1564549985159; Tue, 30 Jul 2019 22:13:05 -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>
In-Reply-To: <D36DCE87-8A9E-4D3E-9241-3BA356D1ACFB@bluejeans.com>
From: Justin Uberti <juberti@google.com>
Date: Tue, 30 Jul 2019 22:12:53 -0700
Message-ID: <CAOJ7v-2o95utN_89-8kDa1ySq3-=4TNfUh4tyyo_adxgorH9XQ@mail.gmail.com>
To: Matthew Kaufman <mkaufman@bluejeans.com>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001a0013058ef32e45"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/YbCTY_0JbdgTIXsL7gaNCMN-BVQ>
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 05:13:09 -0000

On Tue, Jul 30, 2019 at 10:10 PM Matthew Kaufman <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).
>

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>
> *Date: *Wednesday, July 31, 2019 at 10:36 AM
> *To: *Matthew Kaufman <mkaufman@bluejeans.com>
> *Cc: *"tsvwg@ietf.org" <tsvwg@ietf.org>rg>, "rtcweb@ietf.org" <
> 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>
> 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>rg>, "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=>
>
>