Re: [mpls] Concerns about ISD

Tianran Zhou <zhoutianran@huawei.com> Tue, 19 April 2022 04:54 UTC

Return-Path: <zhoutianran@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD503A1244 for <mpls@ietfa.amsl.com>; Mon, 18 Apr 2022 21:54:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.806
X-Spam-Level:
X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 HQe1Mmxny43R for <mpls@ietfa.amsl.com>; Mon, 18 Apr 2022 21:54:28 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937D93A1243 for <mpls@ietf.org>; Mon, 18 Apr 2022 21:54:27 -0700 (PDT)
Received: from fraeml715-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KjBFf50yQz685VR; Tue, 19 Apr 2022 12:50:46 +0800 (CST)
Received: from kwepemi500010.china.huawei.com (7.221.188.191) by fraeml715-chm.china.huawei.com (10.206.15.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 19 Apr 2022 06:54:23 +0200
Received: from kwepemi500009.china.huawei.com (7.221.188.199) by kwepemi500010.china.huawei.com (7.221.188.191) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 19 Apr 2022 12:54:21 +0800
Received: from kwepemi500009.china.huawei.com ([7.221.188.199]) by kwepemi500009.china.huawei.com ([7.221.188.199]) with mapi id 15.01.2375.024; Tue, 19 Apr 2022 12:54:21 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Haoyu Song <haoyu.song@futurewei.com>, Robert Raszuk <rraszuk@gmail.com>
CC: Tony Li <tony.li@tony.li>, "mpls@ietf.org" <mpls@ietf.org>, John E Drake <jdrake@juniper.net>
Thread-Topic: [mpls] Concerns about ISD
Thread-Index: AdhKc4fdvDv9lzMNTfy5c++8iNI9i///poSA//7GfeCAAt4vgP/7wPiAgAhY2QD//2GkAAAn72wA//7TxPD//eE1gP/7NOOg//aGzID/67yBQP/XK+UA/6x794D/V7AIAP6vG0OA/V4yzID6vGKOAPV4wUgA6vF9xYDV4vMTgKvF3LWA14uv0wCvFxZWAN4uHVMAvFgOF4D4sBPvAPFgDAwA4sATwoDFf73RAIr+wkAA
Date: Tue, 19 Apr 2022 04:54:21 +0000
Message-ID: <8fc116fc3c3841bcbe785362e8de98c0@huawei.com>
References: <6cc272447d2f4c779e85d5c42d3b3c6c@huawei.com> <8623637D-A32E-47A4-B5FC-4D2CF40BEDD1@tony.li> <6199e0e886f9437c95ef9b70719b00ec@huawei.com> <BCFD3F4A-36D6-47C2-B907-FC40B402F97C@tony.li> <3fb1f261ddff48deb0c2ea083cdbd16f@huawei.com> <6B96F21B-9331-4FA8-AD7B-84A4CA8B6FAB@tony.li> <903c57a48280454091495673ec2fe275@huawei.com> <BD5C1BE7-4633-4B51-BAC1-B2AE1C537F36@tony.li> <ad6b8c42b0aa4880b9dee02516f5e46f@huawei.com> <F5BB2CEB-CC8C-4E71-A2E7-B4212878C3B1@tony.li> <aa9c4b913d844410b2af90c8db78c194@huawei.com> <BY3PR05MB8081937B52E657713E8293BFC7ED9@BY3PR05MB8081.namprd05.prod.outlook.com> <a29c96be774845e582a66700d2264f7b@huawei.com> <BY3PR05MB8081870EF67C551727BBE2CFC7EC9@BY3PR05MB8081.namprd05.prod.outlook.com> <d5521b3972dd43e38276afbbdc7c2bda@huawei.com> <BY3PR05MB80813C7CAD7F2C12C36FB513C7EE9@BY3PR05MB8081.namprd05.prod.outlook.com> <BY3PR13MB47879EB8A582437DE936688C9AEE9@BY3PR13MB4787.namprd13.prod.outlook.com> <C493D0B8-4B57-4D19-BC27-70ABD7F50356@tony.li> <BY3PR13MB47878B227A37AAA06625194B9AEE9@BY3PR13MB4787.namprd13.prod.outlook.com> <0318B3A3-2884-4FD6-B5EF-377481D2657B@tony.li> <BY3PR13MB4787752FB6D147281A7150789AEE9@BY3PR13MB4787.namprd13.prod.outlook.com> <602D6128-3BE3-4A2D-B5C2-019AE0FADF09@tony.li> <BY3PR13MB47876188B5927A51BD4F4E739AEE9@BY3PR13MB4787.namprd13.prod.outlook.com> <BCB99042-ECA3-40C6-8581-FA1656DDF987@tony.li> <BY3PR13MB4787468DAA96610B9933E1659AF19@BY3PR13MB4787.namprd13.prod.outlook.com> <EB04096F-70B7-4FF0-973F-6C7C1FDDE837@tony.li> <BY3PR13MB47874EBD4E397AB18CD8AF819AF39@BY3PR13MB4787.namprd13.prod.outlook.com> <7451CC1D-88A7-4D13-9BE5-44BCBE95337A@tony.li> <BY3PR13MB478725F22B60E681ABF94BC79AF39@BY3PR13MB4787.namprd13.prod.outlook.com> <CA+b+ERmH2vMizOBJpTRezQRJMU-2Y4y4TL4wzOY+o=yMyDB5qg@mail.gmail.com> <BY3PR13MB4787E7127067365E17C8CA549AF29@BY3PR13MB4787.namprd13.prod.outlook.com>
In-Reply-To: <BY3PR13MB4787E7127067365E17C8CA549AF29@BY3PR13MB4787.namprd13.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.195]
Content-Type: multipart/alternative; boundary="_000_8fc116fc3c3841bcbe785362e8de98c0huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/UXZj5Jv_kl2pFXJOkt8j2LHM5Lk>
Subject: Re: [mpls] Concerns about ISD
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Apr 2022 04:54:33 -0000

Hi Robert,

I agree with you and Haoyu. And I think we can be aligned on this.

Cheers,
Tianran

From: Haoyu Song [mailto:haoyu.song@futurewei.com]
Sent: Tuesday, April 19, 2022 9:49 AM
To: Robert Raszuk <rraszuk@gmail.com>
Cc: Tony Li <tony.li@tony.li>; Tianran Zhou <zhoutianran@huawei.com>; mpls@ietf.org; John E Drake <jdrake@juniper.net>
Subject: RE: [mpls] Concerns about ISD

Hi Robert,

I agree there should be no performance impact to the transit nodes which don't execute the actions.

With SPL+PSD, a transit node only need to identify the SPL and ignore it. But with FAI+ISD, a transit node needs to parse all the FAI and ISD, otherwise, it won't be able to look beyond the first occurrence of FAI into the packet.

Best regards,
Haoyu

From: Robert Raszuk <rraszuk@gmail.com<mailto:rraszuk@gmail.com>>
Sent: Monday, April 18, 2022 12:31 PM
To: Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>>
Cc: Tony Li <tony.li@tony.li<mailto:tony.li@tony.li>>; Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org<mailto:zhoutianran=40huawei.com@dmarc.ietf.org>>; mpls@ietf.org<mailto:mpls@ietf.org>; John E Drake <jdrake=40juniper.net@dmarc.ietf.org<mailto:jdrake=40juniper.net@dmarc.ietf.org>>
Subject: Re: [mpls] Concerns about ISD

All,

I think one point is very fundamental to this discussion.

Whatever "container" is used to contain actions, parameters or even pointers to control plane distributed actions and parameters I proposed it MUST NOT affect performance of transit nodes which are not to execute any special actions.

And if we take this as a requirement then the discussion on where to place those actions performance wise becomes a bit moot - as time spent on executing given actions may very well exceed discussed performance tradeoffs orders of magnitude.

I think Tony and John said this already, but I think this deserves to be highlighted. However no one if I recall mentioned zero impact for non action actors which IMO is a very fundamental requirement for this entire effort.

Thx,
R.






On Mon, 18 Apr 2022 at 21:15, Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>> wrote:
Hi Tony, please see inline comments.

From: Tony Li <tony1athome@gmail.com<mailto:tony1athome@gmail.com>> On Behalf Of Tony Li
Sent: Monday, April 18, 2022 10:36 AM
To: Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>>
Cc: John E Drake <jdrake=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>>; Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org<mailto:40huawei.com@dmarc.ietf.org>>; mpls@ietf.org<mailto:mpls@ietf.org>
Subject: Re: [mpls] Concerns about ISD


Hi Haoyu,


Switch ASICs all use TCAM/CAM to do parsing for performance and NPs use microcode. You are right that in NP microcode you just write "if" branches to parse the headers. But each "if" costs extra clock cycles to process which are very expensive in NPs.


Sorry, I disagree.  Again, compute cycles aren't nearly as expensive as memory operations.

[HS] Here "expensive" means the performance impact. NP is struggling to squeeze every cycle out of the processing, since the throughput is reversely proportional to the number of cycles a packet can finish its processing, and NP's throughput already falls behind ASIC. Engineers need to handcraft the code to save a bit here and there. There's never enough. The cycle is really a precious resource which can't afford to squander.
Have you evaluated how much more complex (e.g., how many more "if") it is to parse the FAI than a simple post-stack header chain? The result might surprise you. The inefficiency of the header encoding applies to any target platforms which will hurt the forwarding performance (or incur high hardware cost) and it will hit the old devices in use even harder.



Yes, I have.  The memory reads for parsing a header chain are extremely high.  No thank you.  The bandwidth requirements for the header chain are extremely high.  No thank you.

[HS] Not sure what you mean here. In ASIC, memory access is really fast. In software, every instruction and data need to be read from memory/cache. The more "if" in the code, the more memory accesses. And why header chain parsing requires higher bandwidth?

Ok, that saves you 4 octets, but costs you a bit in EHI. There's only a finite number of bits available.  What do you do when they're consumed?

[HS3] Resource is always limited everywhere and for any proposal, therefore we need to careful evaluate and admit use cases.


Well, I prefer proposals where there is more flexibility.

[HS] Header chain is more flexible and extensible. It's used for all the headers AFAIK.

--Haoyu

Yes, determining the length requires reading the full ISD.

[HS3]This then would further complicate the parsing.


Considering that the parsing is probably trivial compared to performing the network action, I don't understand the objection.


Absolutely true. Allocate popular functions first. :) If there are too many actions, then we could also consider a second SPL.

[HS3] We only know what's popular for known use cases. We don't know if a use case emerging in future is actually more important.


Agreed. Knowing the unknown is rather difficult.


So EH is twice as expensive as FAI.

[HS3] In terms of header overhead, this is true but only to this specific case. The number depends on how many functions and what functions are supported in a packet. For EH, HEH is a fixed 4 byte overhead, and all the others are equivalent.


This case seems like it might be pretty common.  EL is already common today and is likely to become more common as the use of ECMP proliferates.  I think we can anticipate that slicing will be common as the 5G folks seem to be strongly in favor of it. Mobile clearly isn't going to go away.

Tony


_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=05%7C01%7Chaoyu.song%40futurewei.com%7C50528945a0254e9eeb5308da2171c338%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637859069781439352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cosMWdxG%2FY6L0sSLdP7TETJkFTa4XexrkjO5SfFttUA%3D&reserved=0>