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