[tsvwg] 5G, DiffServ and new PHBs

Ruediger.Geib@telekom.de Mon, 27 April 2020 07:18 UTC

Return-Path: <Ruediger.Geib@telekom.de>
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 40C013A0F2A for <tsvwg@ietfa.amsl.com>; Mon, 27 Apr 2020 00:18:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 lYFIcfNCGp-0 for <tsvwg@ietfa.amsl.com>; Mon, 27 Apr 2020 00:18:28 -0700 (PDT)
Received: from mailout31.telekom.de (mailout31.telekom.de [194.25.225.143]) (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 9BD723A0F13 for <tsvwg@ietf.org>; Mon, 27 Apr 2020 00:18:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1587971907; x=1619507907; h=from:to:cc:subject:date:message-id:mime-version; bh=g4yIVGQtOM+CoUZjEhia7WSPpmma4CjaqNar0sypuDc=; b=cN58qRXizvVhpxoHZa21veiDpYfebEMLHhFS+NGzxpFS7emECXq4LO6O 6I6xLBrBv5fnL5LUTvRYQCQZN2OSeuSbu/sZAQ5jHgOgbczod+9D8qUZX wgS+SsN7eOO9nKB/xr6bna/W7X7Q+Qq2oEYJjZEBdOKs5F+Six7qqddVu oAj6ba/lJRqfGuTmOF9tmq+rGl3DEnDnyb5e1JmEsu9mZynhXOaB9wyDC ocBbPE71JPpPCOoKEIFuFZgwR+CBTiRLz5YB95z1w3G+Vvt498gQPSNfJ pN2ZIyIYms6MA+cl+zALJMjst5r53+hC6hiZrKTbK1rKFgIb+Iw2vVG2j A==;
IronPort-SDR: h727ISJYnQjn48D+4Q9Uq6jHbt4z05KAijvZyiYydPbTkcfXh1SgTPS/yWdmJYMJXqvxduMfW1 JIcOYlEjnKYA==
Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2020 09:18:18 +0200
IronPort-SDR: 8o6k98YInv6r0x6rZYU2Bq5CifgSRHSBykEWAFu5QPR77oyywiTK1jzH9EusUN7SdB8OYadNwF bJ0hQ/bXfit73gJ4WWdHW/7ETxZtbTWMA=
X-IronPort-AV: E=Sophos;i="5.73,323,1583190000"; d="scan'208,217";a="101528838"
X-MGA-submission: MDGarebBi2U3Zbtr52KjldawwViwdVVN4WRJWk55OTJMUDkhhZeepLWd0edMXNFdoguv54V38Cz/IHph2AEtv4h5TSM2hQvahXu05b8CJwD2onVcy1kqucjxTtgiEWFbz+2uuPtQW/GvMVuGdkCWPwl479edp5MhEZF9nd9rsl7ItA==
Received: from he105709.emea1.cds.t-internal.com ([10.169.118.41]) by QDEC97.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 27 Apr 2020 09:18:19 +0200
Received: from HE105712.EMEA1.cds.t-internal.com (10.169.118.43) by HE105709.emea1.cds.t-internal.com (10.169.118.41) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Apr 2020 09:18:18 +0200
Received: from HE104160.emea1.cds.t-internal.com (10.171.40.36) by HE105712.EMEA1.cds.t-internal.com (10.169.118.43) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 27 Apr 2020 09:18:18 +0200
Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.23) by O365mail03.telekom.de (172.30.0.232) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Apr 2020 09:18:16 +0200
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eF/UeNyEieXSx8MXwFngUnDnM+AXWd8+N5CVh43IZvdvdx+ZGb7JW/WG09Fxo9H7OIFAB5+NuPlgi++VtmUw1vSzgHjgR0BuC6qnxGxYMsGsP+vRoIfR8kpHuHQXpbh1+65g9t4DtBks9G9QT6CBw09vYgjvilDzaz6KO70C8zJ7dcPvcBY/KOVVwCGtUVXPWry2vfBcUsapTa0WbpcK2xcgjkyo0pR+muz1lRKZx70j8oV9aoY3BvvArFrZfhQzAlYDZQ97oCa+wAcq4BMcSXzp6piW3DuXwpD6v4WDV8LnEphzd+kzAJcTxx2K/xj1/qjbrJ9u7YJKBdr3jkPETw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g4yIVGQtOM+CoUZjEhia7WSPpmma4CjaqNar0sypuDc=; b=CxJBTh9xDxTmJEQZGLVxzud10pcsoJXq7YMVYGpgYzrCJ42nodbaYe5KiW+KVX8tehIhHe80zgm+7fH8pUPpG9KskB0lkjIisnAGVhNz3aqSh28n8LgDiOWwJAKDozRaUjMIFPnJML6dpIcVxEPnUUNmRJ/SBzySQxdjbczzcVwDFQopcl9LgrelIZ+4NpoI8KNKzJxAFE6402up3OeDJC6tsj/CaU2HKYPq7k1dFhxagW5aXM6v2pbrjgBHsSL6RtghJKekBi8g54Cu5NIJKl58GRtlsm4EQH2iHFoDBFaqzPYlO1wNUYwrbMqxDX6pqzLudKRCusvtxwf7zt1yIg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none
Received: from FRAPR01MB0130.DEUPRD01.PROD.OUTLOOK.DE (10.158.136.154) by FRAPR01MB1154.DEUPRD01.PROD.OUTLOOK.DE (10.158.137.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.23; Mon, 27 Apr 2020 07:18:16 +0000
Received: from FRAPR01MB0130.DEUPRD01.PROD.OUTLOOK.DE ([fe80::454f:d8d:6af0:4264]) by FRAPR01MB0130.DEUPRD01.PROD.OUTLOOK.DE ([fe80::454f:d8d:6af0:4264%8]) with mapi id 15.20.2937.023; Mon, 27 Apr 2020 07:18:16 +0000
From: Ruediger.Geib@telekom.de
To: umac.ietf@gmail.com, jerhenry=40cisco.com@dmarc.ietf.org
CC: tsvwg@ietf.org
Thread-Topic: 5G, DiffServ and new PHBs
Thread-Index: AdYcY0bbiYA+dVWdRDaY5AZaH0gasg==
Date: Mon, 27 Apr 2020 07:18:16 +0000
Message-ID: <FRAPR01MB01305F5494C7B0B371E46E8C9CAF0@FRAPR01MB0130.DEUPRD01.PROD.OUTLOOK.DE>
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.4.138]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4385c045-06fa-4727-d48f-08d7ea7b27f9
x-ms-traffictypediagnostic: FRAPR01MB1154:
x-microsoft-antispam-prvs: <FRAPR01MB1154239E7E997E6AB01189249CAF0@FRAPR01MB1154.DEUPRD01.PROD.OUTLOOK.DE>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 0386B406AA
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FRAPR01MB0130.DEUPRD01.PROD.OUTLOOK.DE; PTR:; CAT:NONE; SFTY:; SFS:(136003)(366004)(346002)(396003)(376002)(39860400002)(2906002)(19627235002)(85202003)(9686003)(81156014)(66446008)(26005)(76116006)(33656002)(186003)(85182001)(71200400001)(8936002)(64756008)(7696005)(30864003)(66946007)(66556008)(55016002)(66476007)(8676002)(478600001)(4326008)(110136005)(5660300002)(316002)(86362001)(66574012)(53546011)(777600001)(559001)(579004); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: WvwRRbODX9DhFqqG+LU7bZI7jdFpPTsBNgxRU9AEaxtekMNeGbxDLzO+hqFJKQhhIvPO0uPBWlUQIVtOuIEFQkzenWVyXEnBVnRyVX5xL0W2Xt3hIdBh9Nkb0u5cNbb5SR1ziR7K6Zqsf2WhFlrG8E3FIrkYrjJTgj91BQIauKM8GoNDNa9fUWl/R/Op0c/Re5YgJ6rOyAcnmv6dglQPgvT6pdmrg79dHHOmWzaiMh4Ar7thhgt0Z+/aXJxvkuM3/mX4KFC0lCRO81FyAbIJdMFGfaEDomk+FC8S7HHtH6JZdXQpgch2Y4UizXvjvp2BhnTjfh8yKyb5qyAXJ+9HcRFhlkGmCWAb8GY/K42Okeg7VqeL2x9oEhfzokV14akwLzEEEDrQamcbKE4jibIHRVceg9mHfq5rwR35u2AfCtIQdfAdlqwKDsrGS79/m6HIZWJ2LSR/EE0jG2baH2a4RGoz910WA1F5+0Z/jCt+quX/gHhkGLg14rqTuzPmIU/C4Z5G0bf/bUG1cwUnU5FgbggWjbX12SvHlSi1cAAj/RQ=
x-ms-exchange-antispam-messagedata: Lu+C5c/EV7WMOcdgXH2DLoJK/sZKm9NzZhrF7Ia9o1o/2YiQLrsWxGhm5xPbNst1z0WYzQwfAzpicbgbQBMt2yfT0BD9KhH+WQD7hcWv2ZDzCCG4OQtIqp71cj4RaqBNhR4+QD6deJrgtdkCXKO+gI0sKj1hK8agkkvmtIS2HlhJSAgUqNSQg+rox0KK3GamHL8jUHSePn9it75VqSfoDKpOOUQoI8A1fpwvXGKBhwLL4yZk2WMxUajUGnwslNWmdos78YPy/gHL0h3N2o6cs+JzQBQIQVjw8oKNUzoyM3M25SvXjlH2KpFDq+ZTEVUkprpCf8vQhROG975mSP7e0vvSckkz3TwSrZOkZrn85RJzi5LPPr8FOy4uQ3QcxYoUbfwcV4piHoMxwxoFIT+dh8uB2REWa0dAJiCV/q3wVE2qSi7orL4p53RbVKXrbEvihoBujxKH9MmuaCP4AfN8cuInxMBGWcxqYkwJZ47OPJioODn70DDMT5cxdYJ0V0m5YIowrITSAL34XUcLwG/+kU7VKQzWvroGyyO3nfc/SLn094P3X4z2k+WxrpUrjFiz3z7kTgCev3+coVSEDDYu9/CxNfPJ1I0/yLS6ziu16bP5MGYW5DnY5NmAB22TaXRakI02AdNr+B+qjxDTUWKfMltApordfRJtPgDkiP3ObnOiEU6PQz0vuZpxnOCFd2cD7DD7O9kAJFkY547xOmI9hY7eou5IMSs9uJQ0UwMqlmeGoZbSwTRJa8p2Yfk1sVmW7FwIyXJqAbBWB4GiC6UGK/wlC9ic4AD5ZxDEfhMGvlY=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_FRAPR01MB01305F5494C7B0B371E46E8C9CAF0FRAPR01MB0130DEUP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 4385c045-06fa-4727-d48f-08d7ea7b27f9
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2020 07:18:16.8296 (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: M7XLdE9skhfBhAFnqKpxLW/BM7p1E/TwxWyNryezuHR5TbB0eOwzsGsjzxGD9vtFEZWvGvvmynINyOsurEA25Rxje5knVYZCLSUyX7TmrVU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB1154
X-TM-SNTS-SMTP: 2FBEDE507BA65BB9AA077F2E200E2F983BF9F634EA24EB384EEBD7252E20AC962000:8
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/991ORE0gQThUmTxRNckbu4QMr7A>
Subject: [tsvwg] 5G, DiffServ and new PHBs
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: Mon, 27 Apr 2020 07:18:35 -0000

Hi Uma, hi Jerome,

regarding codepoints, policies, PHBs and generic approaches, I’d like to add some thoughts…

A first question is, whether you expect DSCPs to bear a standardized end to QoS information for traffic crossing the Internet. I do not. In my experience, the only environment where DSCPs remain unchanged end-to end are tunneled networks and VPNs.

From what I can tell, in a backbone traffic is either loss and delay tolerant or it isn’t. In a backbone, a delay bound is a routing decision, not a scheduling decision, I think.

All consumer access Diffserv deployments I’m aware of come with one or more policy decision points. The one closest to the user doesn’t trust DSCP markings, no matter where they were set. That said, it means that DiffServ policy is based on other criteria than DSCP. Traffic not meeting these criteria is transported by default PHB and marked appropriately.

The only case where there’s trust in DSCPs at these policy decision points is tunneled traffic. But these aren’t consumer access types. The DSCPs accepted by the policy decision points in that case is well defined and small. The number and value of DSCPs within a tunnel can be arbitrary and I have no knowledge about it. Further, DSCPs are mapped (or transported unchanged in the case of a VPN) at interconnection interfaces with a related SLA in place.

From reading mobile specifications, I think to understand that scheduling may cover:

  *   Instant or delayed transmission
  *   A higher or a lower bit-error probability
  *   please add other aspects, like admission control/guaranteed service or guaranteed minimum bandwidth and so on.

New PHBs may be reasonable. But the architecture where these apply should be defined. I think 3GPPs standards inform their reader, that QCIs and their QoS are only valid for the RAN and there for the wireless section, but not end-to-end. That is why GSMA IR.34 aggregates 9 QCI into 4 classes.

An example is bit error rate. It is the same for all packets independent of the queue configuration in a backbone and on a fixed network access. Differentiation doesn’t add value there. Simple configuration and operation then adds values and is preferable to me.

I’m not sure if and then how a datacenter determines (preferred) processing (I mean some way of attaining more resources or faster processing). I’m not sure, whether a DSCP is relevant or the only relevant information there. From my understanding of Segment Routing, there are other options to carry that information, address or label based, I think. I add this, as 5G also intends to support machine to machine communication.














Von: Uma Chunduri <umac.ietf@gmail.com>
Gesendet: Samstag, 25. April 2020 01:55
An: Geib, Rüdiger <Ruediger.Geib@telekom.de>
Cc: Jerome Henry (jerhenry) <jerhenry=40cisco.com@dmarc.ietf.org>; tsvwg@ietf.org
Betreff: Re: [tsvwg] Draft diffuser to QCI v04 posted

 Hi Ruediger ,

Thank you!

You are right about the 9 QCIs, way back (REL 8??). I see now, your comment to private the QCI deployments and the local usage of DSCPs. Let's leave this for a moment now. Though there were bunch of QCI's defined for LTE, only very few QCIs are in use widely (default bearer and voice bearers). We can see the number of defined QCIs increased over a period of time.

Coming to 5G stuff, lot of things changed especially on how this whole things is handled in 3GPP domain i.e., the equivalent 5QI and dynamic QFIs (one example).   But it's expected given the expanded types of UEs and types of traffic more types of 5QIs would be in use (again who knows how this turns out). I also see some gaps (hence some of my questions below), which leads me to question even with all the effort of carving out new code points as this document proposed, if the mapping can be achievable.

Yes, one approach as you said below, could be to wait for emerging QCIs and then start acting.  However, my take on this would be progressing the analysis the way this document attempting but not fully tied to QCIs (if possible of course, as what I suggested changes the whole scope). Appreciate all the efforts from authors. It can also focus on aggregates first as opposed to individual flow level mappings.  The best approach would be to make this in a generic way, where one usage of this could be in cellular domain (LTE/5G). So we don't have to depend fully on any particular generation and can also be used for beyond 3GPP traffic.

There is a need in shared transport scenarios to have not only  for standardized mapping but also for new PHB definition for vendor agnostic deployment in the transport network.

Best,
--
Uma C.




On Wed, Apr 22, 2020 at 11:51 PM <Ruediger.Geib@telekom.de<mailto:Ruediger.Geib@telekom.de>> wrote:
Hi Uma,

Originally, there were 9 standard LTE QCIs (QCI 1 to 9). When I worked on that topic, I saw a list of deployed LTE QCIs. They were in the range 1xx and I was told, that deployment of these “private QCIs” was quite common. At that time (I don’t claim anything else).

I then started to ask for use of standard QCIs. There was neither a standard nor an agreement to deploy, say, QCI 1 for mobile telephony. Then I found out, that one mobile carrier supported mobile telephony by standard QCI 1 and another one by standard QCI 5 (my recollection may be wrong on the exact value).

My take: if the assignment of standard and/or private QCI is left to mobile carriers and that context is local only in a similar way as the deployment and interpretation of DSCP is left to local schemes of IP network operators, then I think there’s no need to assign fixed standard QCI to standard DSCP mappings.

Another approach might be to wait and see whether some QCIs see frequent deployment or whether categories of similar applications are frequently supported by differentiated QCIs (where the QCIs might differ per provider, whereas the idea of assigning differentiated treatment to the category of application is identical). Once that has become clear, a generic mapping proposal QCI to DiffServ might be useful. That could be done independently of the above approach.

Regards,

Ruediger

Von: Uma Chunduri <umac.ietf@gmail.com<mailto:umac.ietf@gmail.com>>
Gesendet: Donnerstag, 23. April 2020 05:09
An: Jerome Henry (jerhenry) <jerhenry=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>>
Cc: Geib, Rüdiger <Ruediger.Geib@telekom.de<mailto:Ruediger.Geib@telekom.de>>; tsvwg@ietf.org<mailto:tsvwg@ietf.org>
Betreff: Re: [tsvwg] Draft diffuser to QCI v04 posted

Apologies for the intrusion here -

Looking for quick clarifications:

a)  Document says
" This

   document specifies a set of 3rd Generation Partnership Project (3GPP)

   Quality of Service (QoS) Class Identifiers (QCI) and 5G QoS

   Identifiers (5QI) to Differentiated Services Code Point (DSCP)

   mappings, to reconcile the marking recommendations offered by the

   3GPP with the recommendations offered by the IETF, so as to maintain

   a consistent QoS treatment between cellular networks and the

   Internet."

 It says internet. I didn't quite get where this mapping is happening from QCI to DSCP; is this in UE or at the AS boundaries  or when when packet gets into 3GPP domain?

b)   For Ruediger : There was a comment below that private QCIs in LTE deployments

" If private QCIs are part of 5G, are they used by large enterprises too? I know that private QCIs saw fair deployment at the start of LTE. The draft doesn’t mention them. I suggest to put them out of scope if you don’t want to deal with them and recommend to check, whether they are still in use and whether their use is standardized and expected for 5G."

I am not really aware of these used in LTE networks (but I could be wrong). Not really sure what do you mean by private QCI ? Could you plz clarify:
Do you mean QCI not defined in TS 23.203 or local mapping to one of the IANA defined DSCP values? Or non-IANA defined DSCP values?

c)  Say, if new code points are allocated as proposed, do we need to specify  similar to 2597  (AF PHB stuff for example) ?

Thanks in advance.

--
Uma C.


On Wed, Apr 22, 2020 at 11:12 AM Jerome Henry (jerhenry) <jerhenry=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote:
Thank you Ruediger,

(please see inline)

Take care

Jerome

From: "Ruediger.Geib@telekom.de<mailto:Ruediger.Geib@telekom.de>" <Ruediger.Geib@telekom.de<mailto:Ruediger.Geib@telekom.de>>
Date: Tuesday, April 21, 2020 at 4:04 AM
To: "Jerome Henry (jerhenry)" <jerhenry@cisco.com<mailto:jerhenry@cisco.com>>
Cc: "tsvwg@ietf.org<mailto:tsvwg@ietf.org>" <tsvwg@ietf.org<mailto:tsvwg@ietf.org>>
Subject: AW: [tsvwg] Draft diffuser to QCI v04 posted

Hi Jerome,

a reasonably large enterprise may run an own DiffServ scheme. Others may use a carrier DiffServ scheme, if there’s one in place for enterprise customers.

5G is designed for enterprise services and some large corporations have licences (or applied at least), that’s correct. You assume or want to offer standard LCI mappings to DiffServ, that’s reasonable.
[jerome] thank you. 100% agree that there are different models. Quite clearly, an enterprise that is entirely DIffserv, or an enterprise that deploys their marking model fully under the guidance of a carrier, likely does not need external guidance.

Some points which should be discussed or at least be put in/out scope of your draft:

  *   Do you expect all standard LCIs to be supported by a single enterprise on a local and/or an end-to-end basis? The draft says no in one section and I do not expect that too.
[Jerome] In ‘standard’ I read ‘defined in the standard’, which what I think you intent (and not a casual equivalent of ‘common’). I doubt that any enterprise would run all these traffic types (unless it becomes a large monopoly spanning multiple verticals). I expect that each enterprise, depending on its domain of operation, will have a few common traffic types, and a few specific traffic types, for which they will seek guidance on QCI/Diffserv equivalence.

  *   if not all standard LCIs are deployed, is there a real need for one fixed DSCP per standard LCI mapping – or might generic guidance be a reasonable alternative?
[Jerome] If we could know which traffic types combinations are never encountered together on any network, then we could bet on using the same DSCP for both. But I am not sure that we can make this determination, and also it may eb possible that a transport network may honor DSCP and carry traffic from multiple entities. This led me to the conclusion that it was preferable to establish a complete list (what maybe Jake calls ‘a library’), with expression of intent for each and possible label, avoiding label overlap as frequently as possible.

  *   If private QCIs are part of 5G, are they used by large enterprises too? I know that private QCIs saw fair deployment at the start of LTE. The draft doesn’t mention them. I suggest to put them out of scope if you don’t want to deal with them and recommend to check, whether they are still in use and whether their use is standardized and expected for 5G.
[Jerome] We can definitely make that mention, although it seemed to me that, as we state that we use TS 23.203 (and TS 23.501 for 5G) as a reference, the implication was there that we did not address private QCIs (as these docs specify that they define standard QCIs/5Qis to ensure interoperability and void non-translatable private QCIs), nor do we address experimental/local DSCPs or private performance characteristics (but making this mention is trivial, I’ll make it).

  *   The abstract of your draft reads (excerpt): “application traffic transits .. between enterprise networks, the Internet, and cellular telecommunication networks….it is crucial that quality of service be aligned between these  different environments….This document specifies a set of QCI to DSCP mappings so as to maintain a consistent QoS treatment between cellular networks and the Internet.  This mapping can be used by enterprises or implementers  expecting traffic to flow through both types of network, and wishing to align the QoS treatment applied to one network under their control with the QoS treatment applied to the other network.”
In your scenario below the sentence “enterprise has a series of assets of various types, and they leverage a dual connection (MPTCP, QUIC etc) between cellular and unlicensed (..WiFi). In addition, an application server is introduced.  In my mind
- leaving the enterprise and interconnecting to a 3rd party application server – is that a direct interconnection or is an upstream carrier involved (the Internet)? In my mind the draft should respect the state-of-the art at the relevant interconnection interfaces. From my experience, DiffServ requires an SLA between interconnected parties. Application servers operating with Diffserv belong to one of them.
The other case is communication of a single VPN across a carrier backbone. In many cases, MPLS is deployed by the backbone. It is a task of the enterprise VPN operators map his DSCP scheme to the offered carrier classes then. As mentioned above, a carrier could offer some pre-defined DSCPs / classes for enterprise VPNs too.
In any case, I’m not sure that I understand which of the above scenarios your draft addresses mainly. That should be clearly expressed by the abstract. I understand you draft aiming mainly at enterprise DSCP to QCI mapping with one end enterprise and other end any part of the Internet by now. If that isn’t correct, please reword the abstract.
[Jerome] I am trying different words to express the content of the draft abstract in case it would be useful. I am not trying to change the scope 😊.  The enterprise is on one end at the UE side, which traffic goes through one 3GPP leg for which an SLA and associated QCIs are likely known, and another leg going through a Diffserv-based leg (which I call Wi-Fi for simplicity). Then the enterprise is on the other end, where traffic re-enters the AS, ie. the domain the enterprise has marking control over. At this point (which may be anywhere beyond the 3GPP boundary), the enterprise will want look at the traffic going through both legs, and make sure it gets the same treatment. The draft can help them think about QCIs, coming from Diffserv, and also, understanding the SLA and the QCIs they agreed upon with the 3GPP carrier, design a Diffserv scheme that would minimize the treatment differences between packets going through these 2 (paths. Hope this helps clarify. Please tell me if you think that the abstract does not convey this intent clearly enough. I am of course open to alternate wording.

Regards,

Ruediger




Von: tsvwg <tsvwg-bounces@ietf.org<mailto:tsvwg-bounces@ietf.org>> Im Auftrag von Jerome Henry (jerhenry)
Gesendet: Montag, 20. April 2020 20:31
An: jholland=40akamai.com@dmarc.ietf.org<mailto:40akamai.com@dmarc.ietf.org>
Cc: jerhenry=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>; tsvwg@ietf.org<mailto:tsvwg@ietf.org>
Betreff: Re: [tsvwg] Draft diffuser to QCI v04 posted

Hi Jake,

This is very useful feedback. In this effort, it seems that we want to arbitrate between different needs. In the scenario we envision, an enterprise has a series of assets of various types, and they leverage a dual connection (MPTCP, QUIC etc) between cellular and unlicensed (let’s call it Wi-FI, although it can be something else). As traffic reaches the other side (application server with at least a Diffserv path to the asset), the hope is that both sides would have treated the packets in an approximatively comparable fashion.

Would you mind exploring your idea a bit further? In all cases, the actor is likely an enterprise IT. They can negotiate an SLA with the carrier(s) they work with. This could result in a series of QCIs attached to the various traffic they would send. Now, their goal is to attempt to get the same intent on both legs. They may not be LTE experts.
In your proposal, how would the choreography work? Would the enterprise create their own mapping between the LCIs their carrier suggested and some DSCP, chosen from unaffected values? (Would they need any guidance on what these QCIs represent? Do we assume that they are comfortable or familiar with the various IETF QoS RFCs?) Would they then use the service.domain logic below to ask the carrier to mark the matching traffic at the interconnect? Or would the host/asset mark the DIffserv side, based on putting in a library somewhere, that the host can access, a service/socket to DSCP table?

Take care

Jerome



Von: tsvwg <tsvwg-bounces@ietf.org<mailto:tsvwg-bounces@ietf.org>> Im Auftrag von Holland, Jake
Gesendet: Dienstag, 14. April 2020 19:38
An: Jerome Henry (jerhenry) <jerhenry=40cisco.com@dmarc.ietf.org<mailto:jerhenry=40cisco.com@dmarc.ietf.org>>; tsvwg <tsvwg@ietf.org<mailto:tsvwg@ietf.org>>
Betreff: Re: [tsvwg] Draft diffuser to QCI v04 posted

Hi Jerome,

Thanks for the update.  To me, cataloging the classes of service for 3gpp seems like useful work for an informational doc, and thanks.

But with regard to the proposed mapping sections, I think there’s a problem:

My current belief is that a static mapping for these classes that can get wide adoption is probably not possible, and it would be a mistake for the IETF to spend substantial effort trying to define one.  And without wide adoption, the use case for things like mobile apps won’t work, except in the most limited and tightly controlled and network-specific ways, because the mobile apps won’t be portable across networks, so the networks will be forced to continue just bleaching markings from IP hosts.  (I’m willing to be convinced otherwise, but it would take some good evidence that all the parties who would need to adopt it are going to be willing to adopt such a thing.)

So I would like to suggest that dynamic negotiation might be worthwhile to define for hosts, as well as at the carrier interconnects.

One key missing piece to make that possible is a signaling system that would be capable of advertising to hosts a mapping between diffserv codepoints and classes of service offered by the network and available to that host.  I believe such a system could be defined in the IETF with a reasonable effort, and that it seems to me it would be a valuable contribution. (*see below for a proposed outline).

Although such an approach might seem technically complicated and harder to deploy compared to a static mapping, it has the advantages that it could scale to many classes of service, it could be extended with new classes of service in the future, classes of service that are not useful within a network can be ignored without cost, and it avoids consuming the scarce and already-overloaded resource represented by diffserv codepoints.

So I’ll suggest that a dynamic mapping at hosts might be an easier path to a deployable solution that actually might be able to address the given use case of being usable by mobile apps, even though it might not be easy.

By contrast with a static mapping, I’d greet a dynamic mapping proposal for hosts with open arms.  More so if the need is urgent enough that it might get some adoption.

On top of the existing needs you’ve outlined, I suspect it’s hard to overstate the future value from enabling incremental deployment for experimental classes.  (And if it drives any knock-on effects encouraging support for mapping of the most useful traffic classes at interconnects, so much the better.)

I hope that’s a helpful comment.

Best regards,
Jake

* As a starting point at a possibly-viable approach, I’ll suggest: 1. define a new service that provides a mapping within a network (with a name added to the iana service names registry), 2. use the domain-name DHCP option to provide the domain name of the local network to hosts acting as DHCP clients, and 3. use DNS-SD to discover the mapping service by combining the network’s domain name with the service name.

Then write a library for use on hosts (or the eNodeB, tho that might have other options), where the API supports requesting a service class for a socket. Make that API discover and query the new mapping service, and on successful discovery of a mapping for that service to a meaningful codepoint for the network, set the target socket to use the discovered codepoint.


From: "Jerome Henry (jerhenry)" <jerhenry=40cisco.com@dmarc.ietf.org<mailto:jerhenry=40cisco.com@dmarc.ietf.org>>
Date: Monday, April 13, 2020 at 11:01 AM
To: tsvwg <tsvwg@ietf.org<mailto:tsvwg@ietf.org>>
Subject: [tsvwg] Draft diffuser to QCI v04 posted

Dear tsvwg,

Following our interim meeting last week, we posted an updated version of draft-diffserv-to-qci (https://datatracker.ietf.org/doc/draft-henry-tsvwg-diffserv-to-qci/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dhenry-2Dtsvwg-2Ddiffserv-2Dto-2Dqci_&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=I0IngIMAy12l9uKMSUXtKPGuTTUZ8uFGgVoSwz2Bs3s&s=HAteQJ46NmpJurRRonWbQ1r5AJbs0gYGVFABCN77MkM&e=>).
This version integrates the feedback that was shared during the interim meeting (formatting error on one table, clarification that no IANA action was mandated).

We discussed extensively on thoughts that were shared during the interim meeting. We had also noticed that several groups had proposed DSCP values for QCI labels. ATIS was named specifically, but other organizations (e.g. NGMN) have proposed such maps. However, we found that the maps available were reflective of a specific point in time, and specific focus. As such, most mapping proposals only consider a small subset of the possible QCIs defined today, and also solely focus on a specific context (which, in the examples above, is typically Carrier to Carrier interconnect). We do not think that these actors need an IETF proposal to decide on how they should mark traffic that they exchange, and such interconnect is better defined in professional settings between Carriers.
By contrast, enterprises that implement dual path (Diffserv on one side, 3GPP on the other) for their UEs are in need of wanting to align their Diffserv markings and treatment to those they have agreed upon with their Carrier, thus creating a requirement different from the above. It seems to us that this draft can help propose such map. Dynamic negotiation (e.g. a-la-RFC 8100) and exchanges (a-la- draft-knoll-idr-qos-attribute-24) are undoubtedly very promising ways of implementing a QoS marking dialog at the interconnection point, but in a world where 3GPP has defined close to 30 traffic types, it seems that there is still a need for us (IETF) to propose a way to express these intents into Diffserv.

We are looking forward to receiving additional feedback on this version.

Best

Jerome