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

Justin Uberti <juberti@google.com> Wed, 31 July 2019 05:06 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 36F51120088 for <tsvwg@ietfa.amsl.com>; Tue, 30 Jul 2019 22:06:48 -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 60D766eG8TFN for <tsvwg@ietfa.amsl.com>; Tue, 30 Jul 2019 22:06:45 -0700 (PDT)
Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 8BC34120075 for <tsvwg@ietf.org>; Tue, 30 Jul 2019 22:06:45 -0700 (PDT)
Received: by mail-vs1-xe29.google.com with SMTP id m8so45378249vsj.0 for <tsvwg@ietf.org>; Tue, 30 Jul 2019 22:06:45 -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=LYDptezAr72Zpsnf7mmc04SCGTlD9LZkultljDP3d/U=; b=rZdKjxyOyQXk0YZhs3h9oB2+JZaYGMinQAYcSynZMHBPI/uNRGMsv1dxKgEmsXBA2j TXceEeHQ/jVV9fh2+tK5BR7V9ZhljJQjpWdpwoX+rE9QTt5IiCtoFru1kV37HQuDCd/N sVcms5MjfzquwJnW4ANSMmXvmD/+001hjGpipgmo6rn4rT8hDPgIYtIH89gC04goV7ak tkSVjekXETkhFDBPrkABzGvVml/fsQiE2b0Zz8/HXMPpmLhXqIeJHTfAa29dm3bcwhLJ ZzcAXujho2ZzPWmjI6BjNRE+K+Jz+QfgUyZC+aoVGoH/MRYHUEHTxLSGZ0WWbK91M8gO ERaA==
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=LYDptezAr72Zpsnf7mmc04SCGTlD9LZkultljDP3d/U=; b=YAsY7OkW6U84PpO+8ZybM+6p/sAYKCOHHktej1tyCYG8sYT0lDF9Lp46riPGjg2oV3 R75z9w3y28l2s3EyTkCeVQWFgiqfpMRWoqWoM1eK5ko7ran2YpWdJFUVrQOnXrgagJEO o1J1WDiNgYhjZx6lkHII8wdbOZp1REhFGtjcZM5vJUzCEtJVMkHn2s/LWKNwwlv9Ewrq 50ORIoMQUhVqtwLmzNsG+LN/MZ+CzYSE7CF55DuXqUdXTHCxGecb00jQo6bJppMfSiyM 2JFhmVRoMMOHSlYG0H/30WsS+uEfh3oakKt85hXweDGtCXaI95TLB+qc9VU/5xjviAnT 2nzQ==
X-Gm-Message-State: APjAAAWrwZOPBKI4ZnRPcEDsbKhw2/mvIxyLuAwqvwiEOVUjMXo0ObVK zuiDbi6STmSjt/E6JeXe4q300+ByEDyXtdOPYGMYKw==
X-Google-Smtp-Source: APXvYqzIc4gPleeh9yJTRZrPOCgvhUsi5nqfXo5wQvt7CbKgVpwLg1qqNNscKjP6bAjysHtuCu6uSuSnTbBQfQamm/8=
X-Received: by 2002:a67:ff0a:: with SMTP id v10mr79603765vsp.1.1564549604032; Tue, 30 Jul 2019 22:06:44 -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>
In-Reply-To: <64D66E22-E816-4AC7-8887-9CDC01A3252C@bluejeans.com>
From: Justin Uberti <juberti@google.com>
Date: Tue, 30 Jul 2019 22:06:32 -0700
Message-ID: <CAOJ7v-2G+w0Luf7OF0xbf+rLOVRHa-QcbWXLmZ+_rLS9wnCA1w@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="000000000000623cb2058ef31782"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/J8Ayr30_dOvKU429pC0GH4fWcPo>
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:06:48 -0000

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