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

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

Return-Path: <juberti@google.com>
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 6A8861200B5 for <rtcweb@ietfa.amsl.com>; Wed, 31 Jul 2019 16:21:25 -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=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 YyQeRsAJCDRf for <rtcweb@ietfa.amsl.com>; Wed, 31 Jul 2019 16:21:22 -0700 (PDT)
Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 183891200FF for <rtcweb@ietf.org>; Wed, 31 Jul 2019 16:21:22 -0700 (PDT)
Received: by mail-vs1-xe30.google.com with SMTP id j26so47555663vsn.10 for <rtcweb@ietf.org>; Wed, 31 Jul 2019 16:21:22 -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=Eb+j5f0s9w1Ul5sSz6VhGRMXCTt1W0q+cLCpuNcy+s8=; b=nwLKXmSfjC5CemGFJWqYXQlUSD8Tonh+gi6RbtIinzgohvjFz8SjftxuKdc9Pk+qbS ZRd4/+rejVQgZYWO+3lc8+lY3APfPqNdoTbtKan8SckhUUeivmbyH58RnX9nu7XzrJm9 ckdD+16qPbABRUmGX/Qk0X9x82b6bBVjFWtdRx1SC4q/kZb3TadFRN2RHoNM+QuIo19Q ExboSC0pQMoqGmyTjyXjWbozEZNi1A41l9qA5Aau74kXM4a5BP6C2YhRPx/gvjrIX+bR LvNMXsqg9SARs/JUdFxdeA5MFjZAUfd2dj6uhymOCL8hTSa5bM9NhJQZV8w0UvX79KAB 68dQ==
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=Eb+j5f0s9w1Ul5sSz6VhGRMXCTt1W0q+cLCpuNcy+s8=; b=ET5gPkRqVKf4IogZxf3rusM/QxsCgllHOXj2GXcf7bkFof1AhHfaOXcEIx9LFUdBH0 5AlcKSvTCbo0NLULR4xCFJY/nthN6U/lnP2yQxzRB4DhYSKkOz0jAPXaaRPwseUP8YOp BYJXN5keDV4eolqphJWu9xSxDZ1ZKh77Hj1Rxz+aWmbaBNjRdo6IwPD2+dpHo6vN0flg GbtSTSf7QbX1z6ZR3O8lZ6Ow3L4lhkbWj+Tdk2hLeauPXMJKwIpR5NwCSx3txYwIrvNY ceEnfsmRXEp1hJvd7qtW7L7fl9ztAiNRyHtu2IuqqwPgjRS5MKo+cjkV9p20bAVFMkPN xMXw==
X-Gm-Message-State: APjAAAVAH/+iqb47JvG9xoaVY5682mIWWmklAO4iakWHX4y4sV9jHt4z ufNw7QCDBoBPTvfC5A8Rwv18VbMSMzI/EjSNe2C7nw==
X-Google-Smtp-Source: APXvYqwm8emP6uw8Cwz41igKL/tPXQc6Kn5QCF2YruhnkdARe+A9HD7t4QNL/J+AI8f1cqO6VN1HYIAoFBLzvox7bJE=
X-Received: by 2002:a67:8d8a:: with SMTP id p132mr79283473vsd.103.1564615280502; Wed, 31 Jul 2019 16:21:20 -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> <3cc1b783-13ed-7a7f-a884-84d5aaa4092d@alvestrand.no>
In-Reply-To: <3cc1b783-13ed-7a7f-a884-84d5aaa4092d@alvestrand.no>
From: Justin Uberti <juberti@google.com>
Date: Wed, 31 Jul 2019 16:21:09 -0700
Message-ID: <CAOJ7v-2sQqqz1OWjrexFvVAou__bRnjN-G0-N9hpvXwA8Ph+iw@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: Matthew Kaufman <mkaufman@bluejeans.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000018711058f02625a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/berad6vJBKVDQttlQzcUSBCel9o>
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 23:21:25 -0000

Great, glad that we've already got this speced. Thanks Harald.

On Wed, Jul 31, 2019 at 7:07 AM Harald Alvestrand <harald@alvestrand.no>;
wrote:

> draft-ietf-tsvwg-rtcweb-qos is out of scope for this working group, but
> didn't we cover this ground extensively in draft-ietf-rtcweb-transport?
>
> Namely (from -17):
>
> 4.2.  Usage of Quality of Service - DSCP and Multiplexing
>
>    When the packet is sent, the network will make decisions about
>    queueing and/or discarding the packet that can affect the quality of
>    the communication.  The sender can attempt to set the DSCP field of
>    the packet to influence these decisions.
>
>    Implementations SHOULD attempt to set QoS on the packets sent,
>    according to the guidelines in [I-D.ietf-tsvwg-rtcweb-qos].  It is
>    appropriate to depart from this recommendation when running on
>    platforms where QoS marking is not implemented.
>
>    The implementation MAY turn off use of DSCP markings if it detects
>    symptoms of unexpected behaviour like priority inversion or blocking
>    of packets with certain DSCP markings.  Some examples of such
>    behaviors are described in [ANRW16].  The detection of these
>    conditions is implementation dependent.
>
>    A particularly hard problem is when one media transport uses multiple
>    DSCP code points, where one may be blocked and another may be
>    allowed.  This is allowed even within a single media flow for video
>    in [I-D.ietf-tsvwg-rtcweb-qos].  Implementations need to diagnose
>    this scenario; one possible implementation is to send initial ICE
>    probes with DSCP 0, and send ICE probes on all the DSCP code points
>    that are intended to be used once a candidate pair has been selected.
>    If one or more of the DSCP-marked probes fail, the sender will switch
>    the media type to using DSCP 0.  This can be carried out
>    simultaneously with the initial media traffic; on failure, the
>    initial data may need to be resent.  This switch will of course
>    invalidate any congestion information gathered up to that point.
>
>    Failures can also start happening during the lifetime of the call;
>    this case is expected to be rarer, and can be handled by the normal
>    mechanisms for transport failure, which may involve an ICE restart.
>
>    Note that when a DSCP code point causes non-delivery, one has to
>    switch the whole media flow to DSCP 0, since all traffic for a single
>    media flow needs to be on the same queue for congestion control
>    purposes.  Other flows on the same transport, using different DSCP
>    code points, don't need to change.
>
>    All packets carrying data from the SCTP association supporting the
>    data channels MUST use a single DSCP code point.  The code point used
>    SHOULD be that recommended by [I-D.ietf-tsvwg-rtcweb-qos] for the
>    highest priority data channel carried.  Note that this means that all
>    data packets, no matter what their relative priority is, will be
>    treated the same by the network.
>
>    All packets on one TCP connection, no matter what it carries, MUST
>    use a single DSCP code point.
>
>    More advice on the use of DSCP code points with RTP and on the
>    relationship between DSCP and congestion control is given in
>    [RFC7657].
>
> Den 31.07.2019 07:12, skrev Justin Uberti:
> >
> >
> > 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).
> >
> >
> > 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=
> >____
> >
>
>