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