Re: [tsvwg] 5G, DiffServ and new PHBs

"Jerome Henry (jerhenry)" <jerhenry@cisco.com> Thu, 14 May 2020 15:30 UTC

Return-Path: <jerhenry@cisco.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 1ECB63A0C8A for <tsvwg@ietfa.amsl.com>; Thu, 14 May 2020 08:30:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=IqhxVQyk; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DmO/a85W
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 gGLwPSdFnQX9 for <tsvwg@ietfa.amsl.com>; Thu, 14 May 2020 08:30:19 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A3693A0C6A for <tsvwg@ietf.org>; Thu, 14 May 2020 08:30:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19359; q=dns/txt; s=iport; t=1589470216; x=1590679816; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Abfj5X3mQOl9bxEthxAriamR72dSGimsvRvBusaKZpg=; b=IqhxVQykYipSN9we0fuwNivJV0FM0+jOlK6kJrdX/k13XU1vmdtVNHnQ 7g93iGH9NBrFs3RP/qjR23eh3Agu3vhtzwpsFUbkb1bzCtX+5A6wsWscO 6OyknJLrVuJfyKmXXDpWIWTj3ZJnM2M9Vzg8+lYRdStEYS7Rl2tKzaGgm 4=;
IronPort-PHdr: 9a23:3KG3bx2u7hUbK6cusmDT+zVfbzU7u7jyIg8e44YmjLQLaKm44pD+JxWGvadkkEOPVoLeuLpIiOvT5qbnX2FIoZOMq2sLf5EEURgZwd4XkAotDI/gawX7IffmYjZ8EJFEU1lorHinLQ5eH8OtL1HXq2e5uDgVHBi3PAFpJ+PzT4jVicn/1+2795DJJQtSgz/oarJpJxLwpgLU5cQ=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BYAQDOYr1e/5BdJa1mHAEBAQEBAQcBARIBAQQEAQGBdgQBAQsBgSQvUQdvWC8sCoQbg0YDjRkliXqJWoRjglIDVAsBAQEMAQEtAgQBAYREAheBfiQ3Bg4CAwEBCwEBBQEBAQIBBQRthSoHJQyFcQEBAQEDEhEdAQE3AQ8CAQgRAwEBASgDAgICHxEUCQgBAQQBDQUigwQBgX5NAy4BpzwCgTmIYXaBMoMBAQEFhTENC4IOCYE4AYJiiV8agUE/gTgMEIFPfj6CHoIHSRYCglwzgi2OVoMEhiGKc49KSgqCTY4ghUCEVB2BIpwnkCyMJpESAgQCBAUCDgEBBYFoI4FWcBU7KgGCPlAYDYYmihqDcopWdDcCBgEHAQEDCXyMA4E1AYEPAQE
X-IronPort-AV: E=Sophos;i="5.73,391,1583193600"; d="scan'208,217";a="766327037"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 May 2020 15:30:14 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 04EFU7hf011002 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 May 2020 15:30:13 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 14 May 2020 10:30:09 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 14 May 2020 10:30:09 -0500
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 14 May 2020 11:30:09 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=neTjSrKGLlI1Ryo4UJ0qLpu+oToOM3Y9ZIk6043zLJ16tOm+Oolwu5Eq3LbUxH2LcLJ9xIPZaqwfIWkAw4m+EAstxiCP1QtcrcOSSlQ1bFzBQ61kP2aVDWcGZKleRFMfx6W4cwsK0PgaQDAJzXnLOkqArSCfcWqHIPQQ4eTJQwaWE/dWSuThIa1P/5SC4bxy/Aj+FfR3ZcACIr4Y4EhMEExMeVzsCqCworNR42yyhSbzZEq8+zEjAt9i/PSAWMgY0GKQZM3Q4OCy1EUMeI8ybBpWs4z0ZwFC6E/pSFuHRh1zBIosDLpeLkIItJqGoLZvBVlxkLOCPJY19Bk8Cjj3nA==
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=Abfj5X3mQOl9bxEthxAriamR72dSGimsvRvBusaKZpg=; b=TINzCmOMjFv6kJcr6vDjDC+qDHbw4NMtYhmwiGvC3znJuJGRxKaP+vB+aeAnZtW9l9kDCUae2fyKqI4rIUxUh0Sq9fb3hyhXjI+tX3tz69N7EWQSwJnBzTQey4j/fAnTf+4kxMQjYorfyBHPrlwTaXXWj0MpvbD23UmznXmRxeRvo28biqXPLiCoWUgrjdVVTWMVDlzNSEbGMGrTDUnoH+ckSivg3j6fm1yaKoEfod+Vp7vfqGxGX2l6Ku7DtGIA2fpMl6Ld4HsLsevA7SFRasQFPUJInneTTWtFwdPkit//cpVC6gusVug3jGuOL+V/rA4tuzIu3Mv5NeDBC1/HtQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Abfj5X3mQOl9bxEthxAriamR72dSGimsvRvBusaKZpg=; b=DmO/a85WvBp+ggTbETYUdSqL6C1YoDeHA/+GJ+nvpUAOTu9i1YDVne3KleNQFxTqB9suVe9n4edV9DaOM5urzmoD/xuiAM0lLEZ7erlPWEfE7PAUjP60A/fKNdtq65vjPCsjE5Rq4yPI+JGMAH+4o8qKI0e1lWjQbAOJ+BcfTsg=
Received: from BN6PR11MB3860.namprd11.prod.outlook.com (2603:10b6:405:77::14) by BN6PR11MB3922.namprd11.prod.outlook.com (2603:10b6:405:7b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.24; Thu, 14 May 2020 15:30:07 +0000
Received: from BN6PR11MB3860.namprd11.prod.outlook.com ([fe80::d49e:4f80:8a82:7d1c]) by BN6PR11MB3860.namprd11.prod.outlook.com ([fe80::d49e:4f80:8a82:7d1c%4]) with mapi id 15.20.3000.022; Thu, 14 May 2020 15:30:07 +0000
From: "Jerome Henry (jerhenry)" <jerhenry@cisco.com>
To: "DOLLY, MARTIN C" <md3135@att.com>, "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>, "umac.ietf@gmail.com" <umac.ietf@gmail.com>
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: 5G, DiffServ and new PHBs
Thread-Index: AdYcY0bbiYA+dVWdRDaY5AZaH0gasgAIFoMAArlw8wAAF30WAAAlqW+gAGFBXwA=
Date: Thu, 14 May 2020 15:30:07 +0000
Message-ID: <C10F73EE-4EEE-4582-9AD2-E71D7704AB78@cisco.com>
References: <FRAPR01MB01305F5494C7B0B371E46E8C9CAF0@FRAPR01MB0130.DEUPRD01.PROD.OUTLOOK.DE> <249939BA-7A98-4E46-B2F3-12BC6B6CE6C9@cisco.com> <FRAPR01MB01309362B0655BE358F57DBB9CA10@FRAPR01MB0130.DEUPRD01.PROD.OUTLOOK.DE> <FE7A000A-0EBA-4EE6-A2B0-3FC8B5960B21@cisco.com> <E42CCDDA6722744CB241677169E836567D6C8974@MISOUT7MSGUSRDB.ITServices.sbc.com>
In-Reply-To: <E42CCDDA6722744CB241677169E836567D6C8974@MISOUT7MSGUSRDB.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.37.20051002
authentication-results: att.com; dkim=none (message not signed) header.d=none;att.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.117.91]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9b1e173e-be30-4027-60db-08d7f81baee4
x-ms-traffictypediagnostic: BN6PR11MB3922:
x-microsoft-antispam-prvs: <BN6PR11MB39228740D0D1F211A79FCC0BD5BC0@BN6PR11MB3922.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 040359335D
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: uAYT3PB+4MnDm/+KBWM8nT4ohUcHjifNpzh8bTcis+Ks4tlluWJ1kiEDibibCzHkUNDVJey14O1aRuFlBVIhrYZVkXkjf5cLHlfeVYiAs6vhr8CFfyM+TUBDIgnwvO1hrXjAZMPscW9PAae5muuDgKspezooVk8ga8trpX5DYjhRFwekoj6GxC3EvJpDWYXT1IDQwkQ4IJ2pLmh9ApuvCvCyeUrfrD0+2irnaI2NpMqFiZDiUnGK/gQLYORDvTfHqQu+dUqY2mBSUWiSoOYMenPfFxHEfjavL9+jeb1jL9LfC1ZlD6SGh3gcywoM8XrEtgAloytnQ6/2nlHDJEWL8WUyGaNZp7YAvFbevs+ikxDU7roXpCKtUQDmKVCjLzsBNRW9fsysiCHwfNmmUVGxU+C2Kb+n+8ZU/weYnjrBvlhH982kgiOLfMvjm0bKCrtz/bJQrsxPavRAMLu5bB1OQ8KWo4yeycZPgus/e1anpmsDXUdLZQeyeJ2JyIgVukPK
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB3860.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(136003)(366004)(396003)(376002)(66476007)(66946007)(316002)(91956017)(76116006)(4326008)(66556008)(66446008)(110136005)(64756008)(2616005)(478600001)(5660300002)(66574014)(33656002)(71200400001)(53546011)(6506007)(2906002)(8676002)(8936002)(36756003)(26005)(6512007)(186003)(86362001)(6486002)(60764002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: Lbm+0YsBIofPhvKtlTPMh25+Ym4MqSejgZqwmIXQvCEyo+ZnR7zWGiUi7YQ07UdFNBzGAC4ru0/uaa82SvgrlQ1NgF5rsoH5gIfJM3KGQCfcld4SzeIXbOKrUDHqPUC5RkFjo2TY1msDRaXCsMyvbucjjhKjXxRXVsFL8y6FIUK7U46kbjs5EHTG8tIeLG7oS108jGY12oKVOHOrU5mA96tDO/v0gd94ocZYz0zCmMCR9TK/TZkiXvbQWCTZuojhqVVnU1ybA9E4Y8Xnrs2NGl99dNqTpaA2L+nBYoSbRqxApC6W15yE5csfO1TpjdT5jP+mOKS2Ttdq2nZocK6ljn+j3K2WUmudZBi4jkeUfElJ2EbTsNTUW7Bq1/lPnpHU5s5AbYZk0uFLR4pxZrin7tlCr00hoXJx9D+QXhKs56FRVPLMyuKFCZ4YOrVulUE/MR6hoYs2p4YGmwZp5XErltOidRwo37CFsOmBn8NlAM9T798QnJHvEG9B5X+zhe1I
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_C10F73EE4EEE45829AD2E71D7704AB78ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9b1e173e-be30-4027-60db-08d7f81baee4
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2020 15:30:07.7842 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: DRa8xEsxZPfIGQnaJXlPnnuPj9a2M/U9GkTPK82mw/SP2PZzMNCo1R2jpJRg/Q1LDVXedmuIVd2VR7via6jziw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB3922
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/kE4UrEt_KhnB5G8v5Mjk9R295zg>
Subject: Re: [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: Thu, 14 May 2020 15:30:28 -0000

Thank you Martin, makes sense.

Take care

Jerome

From: "DOLLY, MARTIN C" <md3135@att.com>
Date: Tuesday, May 12, 2020 at 9:06 AM
To: "Jerome Henry (jerhenry)" <jerhenry@cisco.com>, "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>, "umac.ietf@gmail.com" <umac.ietf@gmail.com>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Subject: RE: 5G, DiffServ and new PHBs

QCI’s with lower latency will be emitted first by the eNB

From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Jerome Henry (jerhenry)
Sent: Monday, May 11, 2020 7:07 PM
To: Ruediger.Geib@telekom.de; umac.ietf@gmail.com
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] 5G, DiffServ and new PHBs

Thank you Ruediger.

I am not sure to fully understand why using a QCI would remove spectrum (it would be congruent to say that DSCPs remove bandwidth on the Internet). I have been thinking about it for a good part of the day, and think that your colleague may be referring to the idea of your second paragraph, that if we allocate more QBRs, then we mechanically reduce access to other traffic, in order to ensure a guaranteed bearer. And if we guarantee bandwidth, we need to make sure that the BW is provided, which also mechanically constraints the access of other traffic over the same radio.

This definitely sounds consistent with what I hear as well. I must say that I have also heard a couple of times the statement “we implement Voice and BE, and don’t care about the rest” from some implementers. But I have also heard very different positions from many others. It seems that the disconnect may come from the notion of small number of users vs bigger number. In essence, it seems to me that a large cell deployed to connect a gazillion of UEs across a very large area will attempt to maximize the overall aggregated throughout. In this environment, I expect BE to be the norm, and Voice QCI to be a necessary luxury. As the cell size decreases, as deployment density (from one or more implementers in the same physical area), the conversation tends to shift to SLA as part of the value proposition. In these environments, I hear the “2 QCI” argument much less often. Obviously, I will not provide specifics, but I will say that implementations do exist, and they are not uncommon in my universe (thus the need for the mapping, it is not an academic exercise).

I remember, after hearing this point (“really only 2 QCIs in the field”) and asking my colleagues working in 3GPP how general this statement was (“it depends” and “it is far from being a universal truth” was their answer), I went to ask more generally (non-Cisco) 3GPP folks if 3GPP had been working, since release 8, year after year, release after release, to add new QCIs consistently, redesigning their scheme deeply with 5G, to put together a growing list of QCIs no one in fact really used or cared about. I think I still have planted in my back a butter knife that was thrown at me as I was running away. I am half joking, but you see my point. If there was 0 adoption, the effort to define more QCIs and deeply rethink the structure for 5QI would likely not have happened. So when I hear that adoption is there, but depends on the location and the implementer, I hear something that is consistent with what I hear about DSCP.

My 2 cents

Jerome



From: "Ruediger.Geib@telekom.de<mailto:Ruediger.Geib@telekom.de>" <Ruediger.Geib@telekom.de<mailto:Ruediger.Geib@telekom.de>>
Date: Monday, May 11, 2020 at 4:31 AM
To: "Jerome Henry (jerhenry)" <jerhenry@cisco.com<mailto:jerhenry@cisco.com>>, "umac.ietf@gmail.com<mailto:umac.ietf@gmail.com>" <umac.ietf@gmail.com<mailto:umac.ietf@gmail.com>>
Cc: "tsvwg@ietf.org<mailto:tsvwg@ietf.org>" <tsvwg@ietf.org<mailto:tsvwg@ietf.org>>
Subject: AW: 5G, DiffServ and new PHBs

Hi Uma, hi Jerome,

after having had a brief discussion with a colleague working on mobile service development, I’d like to add a piece of information. He mentioned that deployment of QCIs comes at a cost of coding space / wireless spectrum. To better utilize wireless spectrum, so far deployment is often limited to one QCI suitable for telephony and one for Best Effort. He doesn’t expect that to change.

He mentioned that supporting more QCIs gives those in some cases guaranteed bandwidth, which will cause blocking of other transmissions until the QCI served terminal received its bandwidth (my terminology might be less than optimal here). The resulting effect is, that a small number of users experience fair Quality of Service, while a bigger number users faces a service degradation.

I recommend to verify that. If that holds, I’d appreciate appropriate text in IETF work relating DiffServ and 3GPP QCIs. To me one point to be discussed then is, whether IETF should set aside reserves or build mechanisms to support technologies of other SDOs, also if the latter are not deployed at significant scale.

Regards,

Ruediger