Re: [6lo] Short Hierarchial IPv6 addresses

2021-11-10 Thread Haoyu Song
Hi Kerry and Alexander,

Thank you very much for the information. It seems the existing standards serve 
their purpose well. But Kerry did mention an interesting point: both these 
networks have low data rate and are insensitive to latency. So maybe for the 
networks or applications where low latency is a critical requirement in 
addition to the bandwidth efficiency, we could find such context-less scheme 
more compelling. This is very helpful discussion. Thanks a lot!

Best regards,
Haoyu

From: Kerry Lynn 
Sent: Wednesday, November 10, 2021 9:04 AM
To: Haoyu Song 
Cc: Alexander Pelov ; Pascal Thubert (pthubert) 
; int-a...@ietf.org; 6lo@ietf.org
Subject: Re: [6lo] Short Hierarchial IPv6 addresses

On Tue, Nov 9, 2021 at 7:15 PM Haoyu Song 
mailto: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 also 
good to know that SCHC already supports direct device communications.  How 
about 6loWPAN? Same?

It is important to note that there are several 6lo data links that employ 
RFC6282
header compression including RFC8163, which is wired. (Indeed, I believe 6282
is a common denominator of published 6lo RFCs.) So, from my perspective, I'd
like your proposal to show why RFC6282 _won't_ work for your application.

Re: quantitative research results for the comparative energy costs of different
6lo design tradeoffs, I believe these studies do exist and folks in t2trg might 
be
able to point you to specific papers. Most (all?) 6lo data links are 
characterized
by low data rates, so it's important to consider the latency win of IPv6 header
compression as an additional consideration.

Regards, Kerry


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo


Re: [6lo] Short Hierarchial IPv6 addresses

2021-11-10 Thread Kerry Lynn
On Tue, Nov 9, 2021 at 7:15 PM 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
> also good to know that SCHC already supports direct device communications.
> How about 6loWPAN? Same?
>
>
>
It is important to note that there are several 6lo data links that employ
RFC6282
header compression including RFC8163, which is wired. (Indeed, I believe
6282
is a common denominator of published 6lo RFCs.) So, from my perspective, I'd
like your proposal to show why RFC6282 _won't_ work for your application.

Re: quantitative research results for the comparative energy costs of
different
6lo design tradeoffs, I believe these studies do exist and folks in t2trg
might be
able to point you to specific papers. Most (all?) 6lo data links are
characterized
by low data rates, so it's important to consider the latency win of IPv6
header
compression as an additional consideration.

Regards, Kerry


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo


[6lo] Heads-up on draft-ietf-6lo-multicast-registration

2021-11-10 Thread Pascal Thubert (pthubert)
Dear all:

With draft-ietf-6lo-multicast-registration, 6lo is extending the IPv6 stateful 
address autoconfiguration (RFC 8505/8928) to express that the node is accepting 
traffic for an anycast address and to subscribe to multicast addresses.

The model is a proactive push from the device, compared to MLD reports that 
pulls from the router. There are a number for reasons for doing this that way 
in energy conscious networks, where multicast and broadcasts are mostly 
prohibited, and devices sleep most of their time. Also the incremental code on 
constrained devices that operate IPv6 ND as per RFC 8505 is very minimal.

The proactive model allows the router to inject the MAC and IP information in a 
network overlay routing or a proxy function in a fashion that is more reliable 
and economical than the classical snooping of MLD and ND. This is why it is 
used in RFC 8929 for proxy ND, and proposed for use in RIFT and now eVPN as the 
IGP-agnostic UNI between the host and the router. 

Since we are extending the registration from unicast to anycast and multicast, 
Erik and Alvaro suggested that we raise the topic on this list as well. 

I would certainly be happy to help folks are interesting in drafting how 
subscriptions learned from this new work can be injected in PIM as well.

Keep safe;

Pascal

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo


Re: [6lo] Short Hierarchial IPv6 addresses

2021-11-10 Thread Alexander Pelov
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 Mess