Dear Haoyu, Thanks for your reply!
See inline On Wed, Nov 10, 2021 at 1:14 AM Haoyu Song <haoyu.s...@futurewei.com> wrote: > Hi Alexander, > > > > Thanks for the clarification! It seems you suggest that the bandwidth > efficiency (i.e., the header overhead) is much more important than the cost > of storage and processing in wireless. It would be great if we could find > some quantitative research results. Is there any such info available? > It's always a tradeoff. That (and others) are also the reason you do Header Compression. Otherwise we'd be just sending out raw IPv6 packets. > It’s also good to know that SCHC already supports direct device > communications. How about 6loWPAN? Same? > Yes, by design. > > > Given all these, can short address, if supported, make things a little > better (i.e., further shrink the header size)? > With SCHC you can go down to 1 bit if you want (here I'm pushing the limit of course, but this serves as an illustration). > Or we believe the current schemes are already good enough and we shouldn’t > bother? > I'd say that the schemes that we have are already good enough. > > > Does this scheme benefit the wifi and other types of wireless networks, > assuming no other HC schemes are applied? > Yes, it does apply. You can run SCHC (and 6LO) on any L2 medium - the point is that in some cases the gain is less than the effort. It's always a tradeoff. If you need to reduce the header sizes, I think you already have an extremely rich set of options in the face of 6LO and SCHC. > > > I’m relatively new to this field and I know there were already tons of > work, so any expert opinions and advices are highly appreciated. Thanks a > lot! > > Sure, you are welcome Cheers, Alexander > > > Best regards, > > Haoyu > > > > *From:* Alexander Pelov <a...@ackl.io> > *Sent:* Tuesday, November 9, 2021 2:05 PM > *To:* Haoyu Song <haoyu.s...@futurewei.com> > *Cc:* Pascal Thubert (pthubert) <pthub...@cisco.com>; int-area@ietf.org; > 6...@ietf.org > *Subject:* Re: [6lo] Short Hierarchial IPv6 addresses > > > > Dear Haoyu, > > > > Thanks for the questions. > > > > A couple of thoughts inline. > > > > > > On Tue, Nov 9, 2021 at 10:25 PM Haoyu Song <haoyu.s...@futurewei.com> > wrote: > > Copied to INTAREA WG because this was also discussed in it. > > Hi Pascal, > > Thank you very much for the suggestions which are very helpful! The high > level idea is indeed drawn from PSTN and PNNI, the proven technologies. > > Our P4 prototype evaluation shows that the extra router processing is > doable with little impact on forwarding performance. Meanwhile, both data > plane and control plane are significantly simplified (e.g., smaller and > regular FIB, simplified routing protocols) which actually leads to lower > router cost. So from the implementation point of view, I have confidence on > it. > > The scheme is applicable to other environments as well, for example, data > center networks, where east-west low-latency communication is dominant. I > agree with you that the discussion is more an IAB one, but some folks in > INTAREA also suggest I may go to 6lo. This makes me a little confused. I > need more advices on how to proceed with the work, and welcome people who > are interested in this work to join me. > > I also have some questions for the 6lowpan and LPWAN header compression > schemes. Aren't the context storage and compression/decompression > computing a source for resource/energy consumption? Is there any evaluation > results on their impact? > > > > The energy cost of a couple of "for" cycles is negligible compared to the > energy necessary for wireless communications. In a more generic setup, the > Static Context Header Compression will depend on the number of static > contexts you have. If I understand correctly the short address proposal, > that would mean roughly one context per address length. Assuming a subnet > has the same 'address length' would mean a single context would suffice, > which means - unmeasurably-small energy consumption (not to say 0). > > > > If shorter addresses are introduced as an additional feature, it may > improve the situation. Another issue I'm concerned is that in 6lowpan/LPWAN > (maybe I'm wrong) it seems that an end node can only talk with a server > through a gateway. I think it may be needed for end nodes to directly > communicate with each other in many cases. If so, do we need some > context-free compression schemes? > > > > The initial way of working for SCHC was indeed in the Device<->Gateway > paradigm. However, it has become quite obvious that there is a direct > extension in a "SCHC Peer" mode (when the Device and the Gateway are > equally capable for example), where there is no need for intermediate > elements. > > > > So, the short answer is - SCHC already has what you want to achieve in > terms of reducing the bits on the air/wire. > > > > Best regards, > > Alexander > > > > > > > > > > > > > > Sorry for the lengthy email. I just wanted to gain a better understanding > on the situation. Thanks! > > Best regards, > Haoyu > > -----Original Message----- > From: Pascal Thubert (pthubert) <pthub...@cisco.com> > Sent: Monday, November 8, 2021 10:08 PM > To: Haoyu Song <haoyu.s...@futurewei.com> > Cc: 6...@ietf.org > Subject: Re: [6lo] Short Hierarchial IPv6 addresses > > Hello Haoyu: > > If I get your proposal well, this is a bottom up aggregation approach when > IP has been traditionally top down. IP extends the prefix length that the > router looks into as we dive down the hierarchy as opposed to building the > address as you extend the reach in this draft. > > At a high level, there’s a bright and a dark side. > > Bright side: > > It can be made to work as proven by other similar mechanisms like domain > name and PSTN. It simplifies the host knowledge of its domain. > > There’s neat routing technology like PNNI that could possibly do a great > job with bottom up aggregation. > > Dark side: > > 6lo does not need a new compression. We already have a simple mostly > stateless one with 6282 and a more complex stateful with SCHC. Too many > standards kill the standard. > > The scheme moves the complexity from the hosts to the network and I’m not > sure what kind of effort it would take to uplift that. In comparison going > IPv6 looks a minor step. In any case this is not a 6lo discussion, more an > IAB one. > > In short I do not recommend to use 6lo as the forum. You need a larger > audience with routing and operations involved. > > Keep safe, > > Pascal > > > Le 9 nov. 2021 à 00:58, Haoyu Song <haoyu.s...@futurewei.com> a écrit : > > > > Hi WG, > > > > In today's session I don't have enough time to finish my presentation. > I think it's important to highlight the difference between our scheme (aka > SHIP) and the compression schemes used by 6LoPAN and LPWAN. Please let me > know if you have further questions or suggestions. > > > > 1. SHIP is hierarchical, extending from edge to core 2. SHIP is > > applicable to all kinds of networks, in contrast to: > > - 6LoPAN: IEEE 802.15 > > 3. SHIP is applicable on arbitrary network topology, in contrast to: > > - HC is applicable on "point-to-point" channel only > > - Compressed packet is not routable unless decompressed first 4. > > SHIP only concerns the IP addresses, orthogonal to the compression > > technique on the other header fields 5. SHIP is solely determined by > > the subnetworks, needing no dynamic context negotiation or static > > context configuration 6. SHIP allows communication between any > > Internet-addressable nodes > > > > Best regards, > > Haoyu > > > > -----Original Message----- > > From: 6lo <6lo-boun...@ietf.org> On Behalf Of Haoyu Song > > Sent: Monday, October 18, 2021 12:11 PM > > To: Michael Richardson <mcr+i...@sandelman.ca>; 6...@ietf.org > > Subject: Re: [6lo] Short Hierarchial IPv6 addresses > > > > Hi Michael, > > > > Thank you very much for your comments! > > I said it's orthogonal to RFC6282 due to the fact that this draft only > concerns about the address part. Since each edge node only needs to keep a > shorter address, the power and storage associated with it are both reduced. > It can be combined with shared context between two nodes (as described in > those context based compression schemes) to achieve further compression. In > this sense, I said they are "orthogonal". > > > > Having said that, I think it can also be a standalone scheme. If the > resulting overhead due to the short address can already satisfy the > application need, then there are merits to use this scheme alone, for the > following reasons: > > 1. Because there is no need to maintain the context between peers, the > storage for context and the computing for compression/decompression can > both be optimized, which I think is critical in the low power and low > capacity IoT scenarios. > > 2. There would be no limitation to the network topology (e.g., star). > Edge nodes can talk to each other directly and communicate with Internet > freely. I think this is another advantage that the other compression > schemes are difficult to achieve but the application may desire to have. > > > > Here are some other clarifications to your questions: > > > > 1. Based on our evaluation, while retaining all IPv6 header information, > our scheme can reduce the IPv6 header overhead from 60% to 70% (i.e., from > 40B to 12~16B). I'll add the evaluation in the future draft revisions. > > > > 2. Yes it can be seen as a static compression scheme, in which the most > compression benefit is from the size reduction of the IP addresses. Since > there will be an IPv6 gateway towards external world, some other header > fields within the edge network can also be reduced or simplified. > > > > 3. The edge network below the IPv6 gateway appears to be a subnetwork to > the Internet. Within the edge network, the network is hierarchical and the > routing in it is straightforward. In the following paper, we described how > the conventional and yet simplified version of IGP and BGP can be used > within the edge network for routing. > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ficnp > > 20.cs.ucr.edu > <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F20.cs.ucr.edu%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb86d37982e71481a8c9e08d9a3ccf6bc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637720923001488608%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cl4hClbyFCzSr6JQvHlbDtor3YxrRvMTmCAI0mTetN0%3D&reserved=0> > %2Fproceedings%2Fnipaa%2FAdaptive%2520Addresses%2520for%2 > > 520Next%2520Generation%2520IP%2520Protocol%2520in%2520Hierarchical%252 > > 0Networks.pdf&data=04%7C01%7Chaoyu.song%40futurewei.com > <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40futurewei.com%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb86d37982e71481a8c9e08d9a3ccf6bc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637720923001498564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=q1WwkK5qVALwX%2FzpDYAkasiH2HG1SEcb62LECRccwLc%3D&reserved=0> > %7C95bdf073 > > 45f94c84ae6a08d9a3475653%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C > > 637720349052868783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo > > iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=g8JFn7V2%2B3i > > cgPEF7ADTaTcPr9DQNOeZjwyRrZR8i24%3D&reserved=0 > > Thanks to the hierarchical architecture, the forwarding table and the > router function will be greatly simplified, which is naturally beneficial > for power, memory and energy. > > > > Best regards, > > Haoyu > > > > -----Original Message----- > > From: Michael Richardson <mcr+i...@sandelman.ca> > > Sent: Monday, October 18, 2021 11:26 AM > > To: Haoyu Song <haoyu.s...@futurewei.com>; 6...@ietf.org > > Subject: Short Hierarchial IPv6 addresses > > > > > > Haoyu Song <haoyu.s...@futurewei.com> wrote: > >> Title: Short Hierarchical IP Addresses at Edge Networks > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-ship-edge%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C95bdf07345f94c84ae6a08d9a3475653%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637720349052868783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=QI%2Bz2Aabf%2BiwCdcTcFVzRx%2BeOkOOO0iIvLFTqLznsiQ%3D&reserved=0 > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-ship-edge%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb86d37982e71481a8c9e08d9a3ccf6bc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637720923001508522%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Boyp0fD4%2Fg%2BtO3wiqSP7LDc6i4UpZHB8cEQSbBd%2FIrM%3D&reserved=0> > . > >> Abstract: To mitigate the IPv6 header overhead in edge networks, this > >> draft proposes to use short hierarchical addresses excluding the > >> network prefix within edge networks. An edge network can be further > >> organized into a hierarchical architecture containing one or more > >> levels of networks. The border routers for each hierarchical level > >> are responsible for address augmenting and pruning. Specifically, > >> the top-level border routers convert the internal IP header to and > >> from the standard IPv6 header. This draft presents an incrementally > >> deployable scheme allowing packet header to be effectively compressed > >> in edge networks without affecting the network interoperability. > >> Presenter: Haoyu Song > >> Purpose: gain awareness and interests from the WG, collect feedback > >> and suggestions for the next step > > > > Interesting. I browsed the document quickly. > > > > I'm not sure I understand how it is "orthogonal" to RFC6282. > > It seems to be an alternative. If it was orthogonal, then it would work > on a different basis vector, and I could use both at the same time. > > > > It seems like you are doing a static compression scheme by re-encoding > > the > > IPv6 header to a new format. > > > > I hope to see some table explaining the size of your header compared to > RFC6282. > > > > Since you have assumed some kind of hierarchal network, would you use > RFC6550 for routing, or is it that you don't need any routing due to your > architecture? > > > > -- > > Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT > consulting ) > > Sandelman Software Works Inc, Ottawa and Worldwide > > > > _______________________________________________ > > 6lo mailing list > > 6...@ietf.org > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > ietf.org > <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb86d37982e71481a8c9e08d9a3ccf6bc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637720923001518479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZaU6SZhq6xC40tlVRRcyheLwwSlOePpDgpMz%2FpjP6Uc%3D&reserved=0> > %2Fmailman%2Flistinfo%2F6lo&data=04%7C01%7Chaoyu.song%40fu > > turewei.com > <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fturewei.com%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb86d37982e71481a8c9e08d9a3ccf6bc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637720923001528433%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xNqTgrhcVd4LFeXUPhq9mTF3dP%2BF0hVzVRCOZb8dleM%3D&reserved=0> > %7C95bdf07345f94c84ae6a08d9a3475653%7C0fee8ff2a3b240189c753 > > a1d5591fedc%7C1%7C1%7C637720349052868783%7CUnknown%7CTWFpbGZsb3d8eyJWI > > joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&a > > mp;sdata=YjW5oU3MLyJdq2LXYgOXxLNU4qSyWTcXGPNyk6vcoL8%3D&reserved=0 > > > > _______________________________________________ > > 6lo mailing list > > 6...@ietf.org > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > ietf.org > <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb86d37982e71481a8c9e08d9a3ccf6bc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637720923001538389%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=q0JGW%2FYIgBIP80dhv%2B9lBiGULLvoi%2B%2BHBW6DD0LApVQ%3D&reserved=0> > %2Fmailman%2Flistinfo%2F6lo&data=04%7C01%7Chaoyu.song%40fu > > turewei.com > <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fturewei.com%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb86d37982e71481a8c9e08d9a3ccf6bc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637720923001548347%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AHxXzuyoIvlhQcovslbGB2KM8dCuBGkwedil2pq0qnk%3D&reserved=0> > %7C95bdf07345f94c84ae6a08d9a3475653%7C0fee8ff2a3b240189c753 > > a1d5591fedc%7C1%7C1%7C637720349052868783%7CUnknown%7CTWFpbGZsb3d8eyJWI > > joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&a > > mp;sdata=YjW5oU3MLyJdq2LXYgOXxLNU4qSyWTcXGPNyk6vcoL8%3D&reserved=0 > _______________________________________________ > 6lo mailing list > 6...@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6lo&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cb86d37982e71481a8c9e08d9a3ccf6bc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637720923001558302%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IwtcTiNT%2BRz1ulGmMW4FhbNwRmuT%2Bdm%2BRTSs6UzIEJs%3D&reserved=0> > >
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
