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

Harald Alvestrand <harald@alvestrand.no> Wed, 31 July 2019 14:07 UTC

Return-Path: <harald@alvestrand.no>
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 377F51200D7; Wed, 31 Jul 2019 07:07:51 -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=ham 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 PKwz7rHSGTOA; Wed, 31 Jul 2019 07:07:48 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C69120077; Wed, 31 Jul 2019 07:07:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id B7E977C3625; Wed, 31 Jul 2019 16:07:46 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BI9Mxt5Fa8Nv; Wed, 31 Jul 2019 16:07:44 +0200 (CEST)
Received: from [192.168.3.17] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id D99D77C32EF; Wed, 31 Jul 2019 16:07:43 +0200 (CEST)
To: Justin Uberti <juberti=40google.com@dmarc.ietf.org>, Matthew Kaufman <mkaufman@bluejeans.com>
Cc: "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>
From: Harald Alvestrand <harald@alvestrand.no>
Openpgp: preference=signencrypt
Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk=
Message-ID: <3cc1b783-13ed-7a7f-a884-84d5aaa4092d@alvestrand.no>
Date: Wed, 31 Jul 2019 16:07:43 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <CAOJ7v-2o95utN_89-8kDa1ySq3-=4TNfUh4tyyo_adxgorH9XQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/QF5JZbC-XcMP67Gp0FE8FaYnVyk>
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 14:07:51 -0000

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