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

[Stewart Bryant <[e-mail]>]

Dear Behcet

You need to read the scenarios draft to see the use cases they have in mind.

I think some people have concerns at the cost of compressing a header, but there seem to be other use cases.

It is up to the authors to build their argument for short addresses I was responding to the case they made.

Stewart


> On 3 Feb 2021, at 15:38, Behcet Sarikaya <[e-mail]> wrote:
> 
> 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 <[e-mail] <mailto:[e-mail]>> 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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/int-area <https://www.ietf.org/mailman/listinfo/int-area>