Dear Haoyu,
Thanks for your reply!
See inline
On Wed, Nov 10, 2021 at 1:14 AM Haoyu Song 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
> *Sent:* Tuesday, November 9, 2021 2:05 PM
> *To:* Haoyu Song
> *Cc:* Pascal Thubert (pthubert) ; int-a...@ietf.org;
> 6lo@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
> 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
