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

<Ruediger.Geib@telekom.de> Wed, 31 July 2019 07:19 UTC

Return-Path: <Ruediger.Geib@telekom.de>
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 7820512009E; Wed, 31 Jul 2019 00:19:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level:
X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
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 4Smu-aAuCmxJ; Wed, 31 Jul 2019 00:19:06 -0700 (PDT)
Received: from mailout21.telekom.de (mailout21.telekom.de [194.25.225.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA8312001B; Wed, 31 Jul 2019 00:19:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1564557544; x=1596093544; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wv1QDl7KXwF+l8b3w8oExljxD0cftK/g77vP2RN2muE=; b=0dmIdTVdDO6A7pFX5hRlB6gkgQnGFBWng30SLOhweiQLztGsrrCZ8CYO 88gbrABfY4zDqLuiONX8kOMoUiqdU77VzwpOJFrR1qSgMGbUgmwbc1M2Y DwmhDE3DUH4BNSoRKcKFzDK3N/M2ZWz4jCROeetEOw1hcWZQHpBe2cX56 DrNb5Is+SQvD9WSU9w47UICfPUOFhZvcYqtljTZDL1iMzwbXVuX84k9uX hmV+YggLXk1GimQ9zD+eDFmjBoK6UuYLiLw2H2X+Fm6xTwNuk4yBOZWkw E3bI+HoNjda9UQ5gvKk8XxXLD3euIqI1BUjwAya7gBzYJlyel/o7uPFJ/ w==;
Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT21.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jul 2019 09:19:00 +0200
X-IronPort-AV: E=Sophos;i="5.64,329,1559512800"; d="scan'208,217";a="470311215"
X-MGA-submission: MDH3tfq2XnJx7tWcjBvnryc7E8047qBEEkgsunZKcDeo9eQgcAEX1MBqvcP7cFBTVA59wD9w760+RYikIkl8W/sP7Lg2bVhRS4CvrCFtBkFRq4vvO8mqIGsDOEnVyQYVUI+XTUWlqr9urLb8ssfypk8Ipj275YiPdmXvPBLvoX/qBA==
Received: from he105865.emea1.cds.t-internal.com ([10.169.119.42]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 31 Jul 2019 09:19:01 +0200
Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE105865.emea1.cds.t-internal.com (10.169.119.42) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 31 Jul 2019 09:19:00 +0200
Received: from HE104162.emea1.cds.t-internal.com (10.171.40.37) by HE199743.EMEA1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 31 Jul 2019 09:19:00 +0200
Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.19) by O365mail04.telekom.de (172.30.0.231) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 31 Jul 2019 09:19:00 +0200
Received: from FRXPR01MB0710.DEUPRD01.PROD.OUTLOOK.DE (10.158.154.26) by FRXPR01MB0776.DEUPRD01.PROD.OUTLOOK.DE (10.158.154.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.15; Wed, 31 Jul 2019 07:19:00 +0000
Received: from FRXPR01MB0710.DEUPRD01.PROD.OUTLOOK.DE ([fe80::64eb:180c:69d1:8be1]) by FRXPR01MB0710.DEUPRD01.PROD.OUTLOOK.DE ([fe80::64eb:180c:69d1:8be1%5]) with mapi id 15.20.2115.005; Wed, 31 Jul 2019 07:18:59 +0000
From: Ruediger.Geib@telekom.de
To: juberti=40google.com@dmarc.ietf.org
CC: rtcweb@ietf.org, tsvwg@ietf.org
Thread-Topic: [tsvwg] [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos
Thread-Index: AQHVR15XOUV7TKNSIESqeuE6AVqH3qbkLnmAgAAWJYCAAAK1AIAACFWQ
Date: Wed, 31 Jul 2019 07:18:59 +0000
Message-ID: <FRXPR01MB0710D9C908354A917443FE6D9CDF0@FRXPR01MB0710.DEUPRD01.PROD.OUTLOOK.DE>
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> <CAOJ7v-3ZDBniXeqQtmp_7FoZjo+v-dMAikQiRuNeQh5AWO_jJg@mail.gmail.com>
In-Reply-To: <CAOJ7v-3ZDBniXeqQtmp_7FoZjo+v-dMAikQiRuNeQh5AWO_jJg@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de;
x-originating-ip: [164.19.3.190]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e6933dd7-e5c9-44f7-06bb-08d715875bb6
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:FRXPR01MB0776;
x-ms-traffictypediagnostic: FRXPR01MB0776:
x-microsoft-antispam-prvs: <FRXPR01MB0776E5960441E55FBBB865309CDF0@FRXPR01MB0776.DEUPRD01.PROD.OUTLOOK.DE>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 011579F31F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(366004)(346002)(136003)(396003)(189003)(199004)(476003)(5660300002)(11346002)(486006)(81156014)(54906003)(19627235002)(186003)(2906002)(256004)(53936002)(76116006)(26005)(14454004)(66946007)(66446008)(66556008)(64756008)(446003)(66476007)(86362001)(71190400001)(71200400001)(7696005)(52396003)(76176011)(68736007)(4326008)(85202003)(66066001)(53546011)(6306002)(54896002)(9686003)(33656002)(81166006)(85182001)(478600001)(55016002)(316002)(8676002)(7736002)(6116002)(790700001)(3846002)(236005)(8936002)(102836004)(777600001); DIR:OUT; SFP:1101; SCL:1; SRVR:FRXPR01MB0776; H:FRXPR01MB0710.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: CgYpIdwWLXqVxQcfz6+Nll/gsqwyGUmr7YKuAhDr0QYsws5/kCDgdh//0avAbZBF326uaWFUTN0pEHGV1ThkGaStAEYVJthZRlLbMaLvrgoX+xpXo7SKA8BXbKai+mNdtP2/s6HsiBf+XjqFlopsP4Y2X6hiZ+iHhSXELLyvrQostA0lbAzaoqRs93k6dX+BDRj5PUmcWosl9tTQFWwPc5GFymCsdX3GjHsup2lRCJHkTTOW7SDrLm8wXLTVu3wh3HxO4cRHznmqnFWFg9uj3tOcbBgBR6Ou8XDfx06RQSiHq3ykkCXSPA+JUxOvJdjnfPW+CAa6IOTbgOF0KJziV4Q43D2876vT/MlUheJvmJsLOY1iWdWatq4OfPxmiuJ3NdsW3TXReA/AZlzjMvsOW0JUlHqo7X0B4x8+ZR00mYg=
Content-Type: multipart/alternative; boundary="_000_FRXPR01MB0710D9C908354A917443FE6D9CDF0FRXPR01MB0710DEUP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e6933dd7-e5c9-44f7-06bb-08d715875bb6
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2019 07:18:59.8569 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Ruediger.Geib@telekom.de
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRXPR01MB0776
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/neT_AktxVsp5oVfSHW3VGpNX1yA>
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 07:19:10 -0000

The conservative approach is to mark traffic by the default DSCP, especially if there’s no QoS SLA between interconnected providers. I’m not sure how many networks drop traffic with unknown DSCPs. If the solution to this issue is to send traffic with a set of DSCPs to figure out what’s passing, the application should also be able to deal with remarked traffic (which I assume to be a network behavior to be expected).

Regards, Ruediger

On Tue, Jul 30, 2019 at 11:32 PM Gorry Fairhurst <gorry@erg.abdn.ac.uk<mailto: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> <mailto: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.