Re: [mpls] Concerns about ISD

Robert Raszuk <rraszuk@gmail.com> Mon, 18 April 2022 19:29 UTC

Return-Path: <rraszuk@gmail.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 435B23A1166 for <mpls@ietfa.amsl.com>; Mon, 18 Apr 2022 12:29:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 bu75KXfnQzFq for <mpls@ietfa.amsl.com>; Mon, 18 Apr 2022 12:29:31 -0700 (PDT)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9C4F3A1162 for <mpls@ietf.org>; Mon, 18 Apr 2022 12:29:31 -0700 (PDT)
Received: by mail-qk1-x729.google.com with SMTP id q75so3266104qke.6 for <mpls@ietf.org>; Mon, 18 Apr 2022 12:29:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=paOueTeSCnLVYpPBpWvdof2UAlK0SsdflvRIxMCifOs=; b=Efd2TWxiMRyneKi7aMQF9WpXbcXJEM4LmYjDRqBgtDJGhbb5m8FbcBAaOn9snaGqkm +ra1nEDgKXIvrkzlojvP9eXGAnxOD5kO+F+rQmI7VvFPaP7UeCuXH33Te3tUx3lsdjRt 18yFBGpG/QTAP92W+HC40ZxYc8UUDnpRFKAVzmPyLY3gf8MFSmAXcoY3tps95952jS51 6j6ltbFNLJrlmAl9M98j4niLV8npqF7KoQpwdD66nQn/qJamEOtcNovIHFD3nGYDHmIW REEU7BOoyPCZ1E1A+nsB1VCmCM/3bv6bF1NIa6FyO2KlePBTIbNPIDsZvVgm5O1B/Fcv IyiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=paOueTeSCnLVYpPBpWvdof2UAlK0SsdflvRIxMCifOs=; b=2tkVVYqAcd0TXmamWF1PQAaf0eljlRxspz8G6LQyvY0xTbCXqTBXcDSbtPprbR+UbP fAalm5b9JkXLtCNm76mu//VTVDlI1D0+qp4H6IWb31omVIneStNXs0BlAML1qNWJj0ef Ph2Z1dxYvoFgr/VzZU3JQBHTdnZnrL9xDn5DJ0kZt3qrMX0E1pcI0x2JA9mCbw+fGM2G bwhKXn+mNYSE1/pXgdzDe5XJaXBDJc5T80CDRnjLXm4w9E1emRAW/y58ahwIOjx/NzBc RSCG3Vt3q1jU46TSkLMd6NC0U6JzvStOFdZgjRUHESG5fF50PrPTOrQj0aEUXsXSSLO6 NFbw==
X-Gm-Message-State: AOAM530tuORxz9CKpV5s+WfmhLoBN0b4Y3fjaUjotIbsxtZNIZI5EPA2 +EvLqx7SBZ3Ela4gmbghkNwSZihClS2C6mE4XrA=
X-Google-Smtp-Source: ABdhPJzKfZ8p+irnxLolj15t0ZllqcQc8Mo43DR6yiQx2HnsLIdhs2Ea2AQ99LOW0nqk3hEQqdcMM5YegLyltupzwOo=
X-Received: by 2002:a37:355:0:b0:69d:a166:ae7e with SMTP id 82-20020a370355000000b0069da166ae7emr7552241qkd.725.1650310170528; Mon, 18 Apr 2022 12:29:30 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <BY3PR13MB478725F22B60E681ABF94BC79AF39@BY3PR13MB4787.namprd13.prod.outlook.com>
From: Robert Raszuk <rraszuk@gmail.com>
Date: Mon, 18 Apr 2022 21:30:43 +0200
Message-ID: <CA+b+ERmH2vMizOBJpTRezQRJMU-2Y4y4TL4wzOY+o=yMyDB5qg@mail.gmail.com>
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Tony Li <tony.li@tony.li>, Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, John E Drake <jdrake=40juniper.net@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007bd1a205dcf2c7fc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/3Q989iITjGLZqrBCBf7yp2qVcqM>
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: Mon, 18 Apr 2022 19:29:37 -0000

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> wrote:

> Hi Tony, please see inline comments.
>
>
>
> *From:* Tony Li <tony1athome@gmail.com> *On Behalf Of *Tony Li
> *Sent:* Monday, April 18, 2022 10:36 AM
> *To:* Haoyu Song <haoyu.song@futurewei.com>
> *Cc:* John E Drake <jdrake=40juniper.net@dmarc.ietf.org>; Tianran Zhou
> <zhoutianran=40huawei.com@dmarc.ietf.org>; 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
> https://www.ietf.org/mailman/listinfo/mpls
>