[Flexip] The small address use case in FlexIP

Stewart Bryant <stewart.bryant@gmail.com> Wed, 03 February 2021 14:08 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: flexip@ietfa.amsl.com
Delivered-To: flexip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CD53A0BDE; Wed, 3 Feb 2021 06:08:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=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 qx4IxvFArOzr; Wed, 3 Feb 2021 06:08:43 -0800 (PST)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 9293F3A0B5A; Wed, 3 Feb 2021 06:08:42 -0800 (PST)
Received: by mail-wm1-x32b.google.com with SMTP id c127so5342629wmf.5; Wed, 03 Feb 2021 06:08:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=VU46ddGpXbk00M/PGFupOITaN91H9Ulhulxvo/BpKco=; b=CS51AO+LgxIWDNUxTdFvnxhrHV4eWd+e9v5+sycLjfmju1S+qefEOQ83ORgXTJ0Ci5 WWyPLFR7mKGz28BAa46x6bPjRXl9Oz8uaYoOwfUPjA+cEOnMxbH+fNPve/6x/+MZq3vs sTlh9TgByBfg6EMPccB7/cvgntehYKdN9BwzSMlaiLs3KQgdi+jqhXNfM/WsQ7R2QVLu /Bo5iKsA0wKHjdGe4Ka7Gn3NMIxTqWjQH9+M4hq0qyyz77YpC7JNrmz3tJ2aEex4BTsO mVeoIPhFPAC0LN3iLeH42wnOnis3b+nhr3bydy5Nb27JYPduMDJwORHz7dLx9ZUDzzkA j1AQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=VU46ddGpXbk00M/PGFupOITaN91H9Ulhulxvo/BpKco=; b=PcsAN4WTYPkSFLJBVDKND9P5fQXdP8zGADWSq9tLyaMHUXCcqLkAm68g2DZ+mYLNow 3J2E6c+N+0nbLMaOeBmxTi1eNgJNkFKjtaeFgNXuE/Cy3/T1M/FBnSlRiIpKlW6cjPGk nhLQdf/HrjRIDgfK171Xs1EmR0ndh/7QsgMd9544cGFU8EGdJV6hWvm9U3jju9zm3tGg Q8+ZVO2kuffkajwzS2OrmWD1hTnLt+Vv6ykt9a30UnPxCQejvTuU/Nu+ftYeffmAFfww x3EPvxCeBDxMxpkNH+8p+tJwzUCKTAT3zgZnrcKaRcmPyWyunsKhH9KjqrD751IcnJ5m X24w==
X-Gm-Message-State: AOAM5330auMUOQSZcw46ukKsVt8wfGn9fA37vDBwTFc92xN6lpY1XaTh SZ1o2WLpYVIL3kXkMiCdmXJcTMqZ5rbGTg==
X-Google-Smtp-Source: ABdhPJwxw5YBAgjJvENuRi1G66TjPgi+9lAwWdMK7DuvLrWp6DmZVNmSwE6WC+5GmaJh3fY8p40WeA==
X-Received: by 2002:a1c:32c4:: with SMTP id y187mr3036808wmy.120.1612361320725; Wed, 03 Feb 2021 06:08:40 -0800 (PST)
Received: from broadband.bt.com ([2a00:23c5:3395:c901:791e:1b4e:f095:65e3]) by smtp.gmail.com with ESMTPSA id t197sm13127457wmt.3.2021.02.03.06.08.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Feb 2021 06:08:40 -0800 (PST)
From: Stewart Bryant <stewart.bryant@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FC2C6DE1-03FE-44CA-B6E5-9BAB15CBB61D"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Message-Id: <051CE5FA-BDCB-4BA3-BE19-2C6FF995AC04@gmail.com>
Date: Wed, 03 Feb 2021 14:08:37 +0000
Cc: Stewart Bryant <stewart.bryant@gmail.com>
To: draft-jia-scenarios-flexible-address-structure@ietf.org, draft-jia-flex-ip-address-structure@ietf.org, flexip@ietf.org, int-area <int-area@ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/flexip/xvhF_j5HcOPpZfRYMq3Qsl1ZDV0>
Subject: [Flexip] The small address use case in FlexIP
X-BeenThere: flexip@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Flexible Internet addressing and Flexible routing <flexip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/flexip>, <mailto:flexip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/flexip/>
List-Post: <mailto:flexip@ietf.org>
List-Help: <mailto:flexip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/flexip>, <mailto:flexip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Feb 2021 14:08:45 -0000

 
Re drafts:
 
https://datatracker.ietf.org/doc/draft-jia-scenarios-flexible-address-structure/ <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-jia-scenarios-flexible-address-structure%2F&data=04%7C01%7Ckiranm%40futurewei.com%7C95b5d102feaf4674ab8408d8c7972448%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637478799262464227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yDi0mFnbU60nFC5PJC%2BAAWVIdSMT%2FY8UO0XIiK3J4iI%3D&reserved=0>
https://datatracker.ietf.org/doc/draft-jia-flex-ip-address-structure/ <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-jia-flex-ip-address-structure%2F&data=04%7C01%7Ckiranm%40futurewei.com%7C95b5d102feaf4674ab8408d8c7972448%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637478799262464227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XB9VFEQiaa0ZMjG5BuF%2FPeQnvFcmGgfY0%2Bye4s7CSoA%3D&reserved=0>
I have a number of comments these drafts, but in this email I would like to focus on the small address proposal. By this I mean addresses that are shorter than 64bits.
 
It seems to me that there are 3 operational reasons for small addresses:
 
1) That you might be worried about the amount of packet taken up by the addresses.
 
2) That you might be worried about the amount of energy required to send a packet.
 
3) That you want to use an address that is somehow native to a legacy application.

… and there are at least to implementation reasons:

4) That you might be worried about the amount of memory in the FIB.
 
5) That you might wish to optimise out the FIB hardware. 
 
There are two approaches to the case of addresses that are are relatively short, where for the purposes of this discussion I define “relatively short” as an address between 8 and 64 bits in length.

One approach is to design and implement a new packet type, be that an original design, or the repurposing of a suitable existing non-IP design. If that is what you have in mind it would greatly assist consideration of your work if you published that design in the IETF, or at least pointed to it as an accessible document. That would allow us to debate the properties of the packet and or your address proposal in the context of the packet design. An alternative approach which needs to be considered is to make the FlexIP address a suffix of an existing and well known address type such as IPv6. In such a case by standardising the corresponding IPv6 prefix you may produce implementation simplifications, or alternatively by making it a prefix well known in the domain you construct quite an effective leakage prevention mechanism.

Consider the IPv6 suffix case. Validating a well-know prefix before invoking the address lookup machinery is a simple efficient process using either one of more compare operators, or some hw technique such as a special register. Certainly we could build hw to look up a small set of well-known prefixes that burns a lot less energy than used in a full address lookup. So that brings us to looking up the suffix and, by definition the table used to do that is small.
In other words most of the efficiency of doing a short address lookup can be maintained even if the address is the suffix of a longer address provided that the implementation is optimised for this case.
 
I think that argument covers much of use cases 3, 4 and 5. This applies to your Indexes 1..EF, F0, F1 and F2 in your propose address design.
 
In your F5 case a longest match engine will work by definition on a variable length address, provided it is short enough that sufficient addresses from the primary address space can be deployed to this. Note that you can throw the address length into the longest match engine if you wish and it will simply consume it and if correctly programmed will return the correct result. Thus any of the address definitions that do not contain discontinuous substructure such as the cases with inbuilt segment routing can be looked up in a common hardware address recognition engine without analysis of the first byte.
 
Now I think that it is worth looking at case 1 and 2 above and noting there is some applicability to both the short address cases and the segment routing case with short addresses that you propose.
 
Of course it is very difficult to do an accurate analysis these cases because the packet design that FlexIP is going to be used with is not referenced by the drafts.
 
Let us assume a tiny packet:
 
14B of MAC header (Lora is 13 to 28, Ethernet is 14)
8B of UDP
2B of payload
 
That is 24B + NW layer (the addresses plus the overhead)
 
Now consider IPv6 which is pretty minimalist for a connectionless packet apart from the size of its addresses.
 
IPv6 is 40B 
 
So total of 64B for the packet which is the benchmark since it is the IETF plan of record for most applications.
 
If we reduce the addresses to 1B (the minimum in these drafts) i.e. subtract 32 - 2 = 30 so best case is packet of 34B. 
 
That is a useful saving 47% which might be important in some specialist applications where bandwidth or radio energy was important, however  much depends on what the practical size of the payload in, and what options or extensions are in the packet to fulfil the  communications needs. So for example if I were to need an additional 20B of packet option and payload the saving is reduced to 36% reducing to 20% saving if 100B were needed. A 20% saving is not worth the cost and complexity of changing the packet.
 
So, to understand the benefit of reducing the address size and presumably using it in an as yet undefined packet format it is necessary for the authors to describe the application for small standalone addresses (as opposed to address suffixes) in a lot more detail than is provided in the scenarios document, in particular the size of the transport layer, and the size of the expected payload. Additionally it is necessary that they describe the details of the network layer packet and its MAC environment.
 
Once more detail is know, we will know whether there is a case for small native addresses or whether we should focus our attention on how to map such addresses as suffixes of a larger well known address type such as IPv6.
 
- Stewart