Re: [Int-area] The small address use case in FlexIP

Behcet Sarikaya <sarikaya2012@gmail.com> Wed, 03 February 2021 15:38 UTC

Return-Path: <sarikaya2012@gmail.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850F23A0A02 for <int-area@ietfa.amsl.com>; Wed, 3 Feb 2021 07:38:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.747
X-Spam-Level:
X-Spam-Status: No, score=-1.747 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 exXEJIOCR8tJ for <int-area@ietfa.amsl.com>; Wed, 3 Feb 2021 07:38:46 -0800 (PST)
Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 2487C3A09DE for <int-area@ietf.org>; Wed, 3 Feb 2021 07:38:46 -0800 (PST)
Received: by mail-yb1-xb2a.google.com with SMTP id c3so6680ybi.3 for <int-area@ietf.org>; Wed, 03 Feb 2021 07:38:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=7XA2HRdkn4wqGcMQkjO67x+Yfr0bH5Rh1t5cFSZXMBQ=; b=UY/hPO3yjzUcrRD6U0Ha0EEkTH2iquqrMvzTnd9GvFrq6LhacxUNaathoDPAPOXOWJ Nj3+7QIrWkJeAvYe1LOrYVa5HPZy497tw1cPYiBNeCHFLfwHUg80YhSsJSnJ8PMPVBad NZqUnK9R0IanNtIezuwmFfB3gPn6oIWuHcqGcYXsHZeDN7KPvntjMdXLDVgZ/R293NXw Z6HhKfNXhPbQJ13GrahnloKYSEzTtGaV8EfvI6hO/qG4pBGg5kC2DydJLBqw7rIUlJp0 0P0NObYuqArZIvEDKp6N3cu6OHNJUBo3/sNcMTAy1XkkKEcdrfxPQRpBi18PC+hrpQd7 Hsng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=7XA2HRdkn4wqGcMQkjO67x+Yfr0bH5Rh1t5cFSZXMBQ=; b=ReNA23ASLo16fwRPjc4YsYnoFZaLTJczumDUvBxBPLsj0ePl96zFUBU4KsbHZoloi5 cW0Pw786HDvKiFoguCaQmvBuHZvaTLQpggSeZyBW+6iX7cUth9ehjF5zicsznVMz4Aek Y8+NAIc10RZTxh5IqChfXKZhKaoM46mK7HsyfQOo0GEkHcSb1StKBgA4964IWhsdFLaM EHbjxjsAaMtF/H8nBCzY74kUHa2vd+N45/XQsQH8wuo9CTahpQW0njK9DWzfhMZUCMnY JrW3TkLKkq9VmJLuQ9YhvZA/zV8OzOFPoNgUPoodNFxzEPEMIrMuHwOInN3RZnFDcg3L 7ArQ==
X-Gm-Message-State: AOAM533uFHmWv82/dvNJgkU9lQZP/ztdd7pvcwSy6cklG1BP9k8ZpvHB YKOYR0QWdL1+i6ESibBqoiOo07McgzgkHNf9kmg=
X-Google-Smtp-Source: ABdhPJxRLIlSIQe7CmAuhkCBnVhZCPNVYdlj0FYUzzCShMQaGSj2vEBAm7WDCPlNPI8W8Ngnuu1Mtrk8zP0S8iqUxIw=
X-Received: by 2002:a25:c3c4:: with SMTP id t187mr4987205ybf.175.1612366725157; Wed, 03 Feb 2021 07:38:45 -0800 (PST)
MIME-Version: 1.0
References: <051CE5FA-BDCB-4BA3-BE19-2C6FF995AC04@gmail.com>
In-Reply-To: <051CE5FA-BDCB-4BA3-BE19-2C6FF995AC04@gmail.com>
Reply-To: sarikaya@ieee.org
From: Behcet Sarikaya <sarikaya2012@gmail.com>
Date: Wed, 03 Feb 2021 09:38:34 -0600
Message-ID: <CAC8QAce77S5J+DODr-JHhdeoWY2uH-QWMh=be=Fi6YHgonW77g@mail.gmail.com>
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: int-area <int-area@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e6983705ba7061a4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/xYBh1F2e0pqEwQKs_mxIWdcynrQ>
Subject: Re: [Int-area] The small address use case in FlexIP
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Feb 2021 15:38:49 -0000

Hi Stewart,

Thanks for your analysis.
I haven't read the drafts you mentioned but I thought that the address size
issue was long resolved with the IPv6:

basically it matters on the wireless medium and this is solved by the
so-called ROHC RObust Header Compression,
which is adapted by 5G and it works well.
Wired medium case which seems to be the main focus according to your mail,
was considered moot, the routers would be able handle it and on the medium
it does not delay things much.

Behcet

On Wed, Feb 3, 2021 at 8:09 AM Stewart Bryant <stewart.bryant@gmail.com>
wrote:

>
> 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
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>