Subject: Re: [6lo] Short Hierarchial IPv6 addresses

From: Haoyu Song <[email-masked]>
Date: Mon, 8 Nov 2021 23:57:51 +0000

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 <[email-masked]> On Behalf Of Haoyu Song
Sent: Monday, October 18, 2021 12:11 PM
To: Michael Richardson <[email-masked]>; [email-masked]
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%2Ficnp20.cs.ucr.edu%2Fproceedings%2Fnipaa%2FAdaptive%2520Addresses%2520for%2520Next%2520Generation%2520IP%2520Protocol%2520in%2520Hierarchical%2520Networks.pdf&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C023d95d26e22445b5d6608d9926b2342%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637701811141856874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=nEGmDFjRHO2ouowt9an5h1mneyP0WxVhCtezy86mcAg%3D&amp;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 <[email-masked]> 
Sent: Monday, October 18, 2021 11:26 AM
To: Haoyu Song <[email-masked]>; [email-masked]
Subject: Short Hierarchial IPv6 addresses

Haoyu Song <[email-masked]> 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&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C023d95d26e22445b5d6608d9926b2342%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637701811141856874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=ctNHIfM9cKlNOuLsxvxPd63XIsT1tCD5UICXDGTM63I%3D&amp;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 <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

_______________________________________________
6lo mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6lo&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C023d95d26e22445b5d6608d9926b2342%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637701811141856874%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=XoiNoRafEZc1zZpno7J3iA%2FV%2BujVPIwGCr1HDpGOk9M%3D&amp;reserved=0

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 9 Nov 2021 06:07:50 +0000

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 <[email-masked]> a écrit :
> 
> Hi WG,
> 
> https://www.ietf.org/mailman/listinfo/6lo

---

From: Haoyu Song <[email-masked]>
Date: Tue, 9 Nov 2021 18:17:28 +0000

>From the meeting note: 
Eduard V: Dual homing to different Carriers would prevent the possibility for the variable destination addresses. Hence, DA would probably stay fixed. Source address could grow on every router upstream.

Hi Eduard,
Thanks for the question! I think even one network has multiple gateways, they should all own the same prefix and work  in anycast fashion, so the DA can be pruned when a packet enters a network. Do you think this works?

Best regards,
Haoyu

-----Original Message-----
From: Haoyu Song 
Sent: Monday, November 8, 2021 3:58 PM
To: [email-masked]
Subject: RE: Short Hierarchial IPv6 addresses

Hi WG,

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 <[email-masked]> On Behalf Of Haoyu Song
Sent: Monday, October 18, 2021 12:11 PM
To: Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [6lo] Short Hierarchial IPv6 addresses

Hi Michael,

Best regards,
Haoyu

---

From: Haoyu Song <[email-masked]>
Date: Tue, 9 Nov 2021 21:25:25 +0000

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? 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? 

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) <[email-masked]> 
Sent: Monday, November 8, 2021 10:08 PM
To: Haoyu Song <[email-masked]>
Cc: [email-masked]
Subject: Re: [6lo] Short Hierarchial IPv6 addresses

Hello Haoyu:

Bright side:

Dark side:

Keep safe,

Pascal

> 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
>    - 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
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ficnp
> 20.cs.ucr.edu%2Fproceedings%2Fnipaa%2FAdaptive%2520Addresses%2520for%2
> 520Next%2520Generation%2520IP%2520Protocol%2520in%2520Hierarchical%252
> 0Networks.pdf&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C95bdf073
> 45f94c84ae6a08d9a3475653%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C
> 637720349052868783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=g8JFn7V2%2B3i
> cgPEF7ADTaTcPr9DQNOeZjwyRrZR8i24%3D&amp;reserved=0
>> 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&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C95bdf07345f94c84ae6a08d9a3475653%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637720349052868783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=QI%2Bz2Aabf%2BiwCdcTcFVzRx%2BeOkOOO0iIvLFTqLznsiQ%3D&amp;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 
>> Purpose: gain awareness and interests from the WG, collect feedback 
>> and suggestions for the next step
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2F6lo&amp;data=04%7C01%7Chaoyu.song%40fu
> turewei.com%7C95bdf07345f94c84ae6a08d9a3475653%7C0fee8ff2a3b240189c753
> a1d5591fedc%7C1%7C1%7C637720349052868783%7CUnknown%7CTWFpbGZsb3d8eyJWI
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&a
> mp;sdata=YjW5oU3MLyJdq2LXYgOXxLNU4qSyWTcXGPNyk6vcoL8%3D&amp;reserved=0
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2F6lo&amp;data=04%7C01%7Chaoyu.song%40fu
> turewei.com%7C95bdf07345f94c84ae6a08d9a3475653%7C0fee8ff2a3b240189c753
> a1d5591fedc%7C1%7C1%7C637720349052868783%7CUnknown%7CTWFpbGZsb3d8eyJWI
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&a
> mp;sdata=YjW5oU3MLyJdq2LXYgOXxLNU4qSyWTcXGPNyk6vcoL8%3D&amp;reserved=0

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 9 Nov 2021 23:04:43 +0100

Dear Haoyu,

Thanks for the questions.

A couple of thoughts inline.

On Tue, Nov 9, 2021 at 10:25 PM Haoyu Song <[email-masked]> wrote:

> 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

> 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.
>
> 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.
>
> 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
>
> > 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.
> >
> > 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.
> >
> > 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.
> > 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
> >
> >> 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&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C95bdf07345f94c84ae6a08d9a3475653%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637720349052868783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=QI%2Bz2Aabf%2BiwCdcTcFVzRx%2BeOkOOO0iIvLFTqLznsiQ%3D&amp;reserved=0
> .
> > 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.
> >
> > 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?
> >
> > --

---

From: Haoyu Song <[email-masked]>
Date: Wed, 10 Nov 2021 00:14:47 +0000

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?

Given all these, can short address, if supported, make things a little better (i.e., further shrink the header size)?
Or we believe the current schemes are already good enough and we shouldn’t bother?

Does this scheme benefit the wifi and other types of wireless networks, assuming no other HC schemes are applied?

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!

Best regards,
Haoyu

From: Alexander Pelov <[email-masked]>
Sent: Tuesday, November 9, 2021 2:05 PM
To: Haoyu Song <[email-masked]>
Cc: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [6lo] Short Hierarchial IPv6 addresses

Dear Haoyu,

On Tue, Nov 9, 2021 at 10:25 PM Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:
Copied to INTAREA WG because this was also discussed in it.

Hi Pascal,

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

Best regards,
Haoyu

-----Original Message-----
From: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Sent: Monday, November 8, 2021 10:08 PM
To: Haoyu Song <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [6lo] Short Hierarchial IPv6 addresses

Hello Haoyu:

Bright side:

Dark side:

Keep safe,

Pascal

> Le 9 nov. 2021 à 00:58, Haoyu Song <[email-masked]<mailto:[email-masked]>> a écrit :
>
> Hi WG,
>
> From: 6lo <[email-masked]<mailto:[email-masked]>> On Behalf Of Haoyu Song
> To: Michael Richardson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> 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
> 0Networks.pdf&amp;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
> From: Michael Richardson <[email-masked]<mailto:[email-masked]>>
> To: Haoyu Song <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> Haoyu Song <[email-masked]<mailto:[email-masked]>> 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&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C95bdf07345f94c84ae6a08d9a3475653%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637720349052868783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=QI%2Bz2Aabf%2BiwCdcTcFVzRx%2BeOkOOO0iIvLFTqLznsiQ%3D&amp;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>.
> Michael Richardson <[email-masked]<mailto:[email-masked]>>   . o O ( IPv6 IøT consulting )
> [email-masked]<mailto:[email-masked]>
> 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&amp;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
> [email-masked]<mailto:[email-masked]>
> 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&amp;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
_______________________________________________
6lo mailing list
[email-masked]<mailto:[email-masked]>
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>

---

From: Alexander Pelov <[email-masked]>
Date: Wed, 10 Nov 2021 10:29:47 +0100

Dear Haoyu,

Thanks for your reply!

See inline

On Wed, Nov 10, 2021 at 1:14 AM Haoyu Song <[email-masked]> 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

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 <[email-masked]>
> *Sent:* Tuesday, November 9, 2021 2:05 PM
> *To:* Haoyu Song <[email-masked]>
> *Cc:* Pascal Thubert (pthubert) <[email-masked]>; [email-masked];
> [email-masked]
> *Subject:* Re: [6lo] Short Hierarchial IPv6 addresses
>
>
>
> Dear Haoyu,
>
>
>
> > 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
> > 0Networks.pdf&amp;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
> <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>
> .
> > 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&amp;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
> > 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&amp;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
> <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>
>
>

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 10 Nov 2021 12:03:51 -0500

On Tue, Nov 9, 2021 at 7:15 PM Haoyu Song <[email-masked]> wrote:

> 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

<snip>

---

From: Haoyu Song <[email-masked]>
Date: Wed, 10 Nov 2021 22:25:23 +0000

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 <[email-masked]>
Sent: Wednesday, November 10, 2021 9:04 AM
To: Haoyu Song <[email-masked]>
Cc: Alexander Pelov <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [6lo] Short Hierarchial IPv6 addresses

On Tue, Nov 9, 2021 at 7:15 PM Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alexander,

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

<snip>

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 11 Nov 2021 09:08:00 -0800

Great discussion and inputs from many header compression experts.

>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.

I can with certainty give 2 such examples where I was involved multiple
times w.r.t IPv6 usage:

1. A subset of mIOT UEs (this is a huge swath of UEs we are talking about)
which needs low latency, high bandwidth and is sensitive to battery power.
For example, a V2X UE, cares for low latency and high bandwidth *but is not
*necessarily constrained by low battery power (though saving is always
good). However, an AR/VR UE (advanced handset or 5G enabled headset) cares
for all 3 (high BW, low latency and battery).

2. Another  one is with LEO satellite constellations and communication from
the end points. Here also only a subset of use cases/devices cares for all
3.

regards!
--
Uma C.

On Wed, Nov 10, 2021 at 2:26 PM Haoyu Song <[email-masked]> wrote:

> 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 <[email-masked]>
> *Sent:* Wednesday, November 10, 2021 9:04 AM
> *Cc:* Alexander Pelov <[email-masked]>; Pascal Thubert (pthubert) <
> [email-masked]>; [email-masked]; [email-masked]
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: Haoyu Song <[email-masked]>
Date: Thu, 11 Nov 2021 19:09:37 +0000

Thanks Uma, those are really great use cases. I would like to include them in the new revisions. My feeling is that a universal scheme like this can benefit many applications/networks (some yet to be explored) and won't introduce unnecessary conflicts and burdens to well-developed HC techniques for 6loWPAN and LPWAN.
We look forward to collaborations and suggestions on where we should land this work. Please let me know if you are interested.

Best regards,
Haoyu

From: Uma Chunduri <[email-masked]>
Sent: Thursday, November 11, 2021 9:08 AM
To: Haoyu Song <[email-masked]>
Cc: Kerry Lynn <[email-masked]>; [email-masked]; Alexander Pelov <[email-masked]>; [email-masked]
Subject: Re: [Int-area] [6lo] Short Hierarchial IPv6 addresses

>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.

I can with certainty give 2 such examples where I was involved multiple times w.r.t IPv6 usage:

1. A subset of mIOT UEs (this is a huge swath of UEs we are talking about) which needs low latency, high bandwidth and is sensitive to battery power. For example, a V2X UE, cares for low latency and high bandwidth but is not necessarily constrained by low battery power (though saving is always good). However, an AR/VR UE (advanced handset or 5G enabled headset) cares for all 3 (high BW, low latency and battery).

2. Another  one is with LEO satellite constellations and communication from the end points. Here also only a subset of use cases/devices cares for all 3.

regards!
--
Uma C.

On Wed, Nov 10, 2021 at 2:26 PM Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kerry and Alexander,

Best regards,
Haoyu

From: Kerry Lynn <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, November 10, 2021 9:04 AM
To: Haoyu Song <[email-masked]<mailto:[email-masked]>>
Cc: Alexander Pelov <[email-masked]<mailto:[email-masked]>>; Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [6lo] Short Hierarchial IPv6 addresses

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?

Regards, Kerry

<snip>
_______________________________________________
Int-area mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fint-area&data=04%7C01%7Chaoyu.song%40futurewei.com%7C5d70d3eb6e004615e20408d9a535d7df%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637722472949487607%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lIBaLwEqPqd%2FnxpK2l102%2BvPZf8EqQau0ZNvJlx7cdA%3D&reserved=0>

---

From: Adnan Rashid <[email-masked]>
Date: Fri, 12 Nov 2021 01:06:54 +0100

Hi Haoyu,

Consider if you have multi tenant network, then will your scheme work?

If yes then how can node A from Service Provider-A can communicate with
node B from Service Provider-B and both are under the same border router or
edge node?

Regards,

Adnan Rashid

On Thu, Nov 11, 2021, 20:10 Haoyu Song <[email-masked]> wrote:

> Thanks Uma, those are really great use cases. I would like to include them
> in the new revisions. My feeling is that a universal scheme like this can
> benefit many applications/networks (some yet to be explored) and won’t
> introduce unnecessary conflicts and burdens to well-developed HC techniques
> for 6loWPAN and LPWAN.
>
> We look forward to collaborations and suggestions on where we should land
> this work. Please let me know if you are interested.
>
>
>
> Best regards,
>
> Haoyu
>
>
>
> *From:* Uma Chunduri <[email-masked]>
> *Sent:* Thursday, November 11, 2021 9:08 AM
> *Cc:* Kerry Lynn <[email-masked]>; [email-masked]; Alexander Pelov <
> [email-masked]>; [email-masked]
> *Subject:* Re: [Int-area] [6lo] Short Hierarchial IPv6 addresses
>
>
>
>
>
> For example, a V2X UE, cares for low latency and high bandwidth *but is
> not *necessarily constrained by low battery power (though saving is
> always good). However, an AR/VR UE (advanced handset or 5G enabled headset)
> cares for all 3 (high BW, low latency and battery).
>
>
>
> 2. Another  one is with LEO satellite constellations and communication
> from the end points. Here also only a subset of use cases/devices cares for
> all 3.
>
>
>
> regards!
>
> --
>
> Uma C.
>
>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fint-area&data=04%7C01%7Chaoyu.song%40futurewei.com%7C5d70d3eb6e004615e20408d9a535d7df%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637722472949487607%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lIBaLwEqPqd%2FnxpK2l102%2BvPZf8EqQau0ZNvJlx7cdA%3D&reserved=0>
>

---

From: Haoyu Song <[email-masked]>
Date: Fri, 12 Nov 2021 00:52:36 +0000

Hi Adnan,

Thank you for the question! In our architecture, the edge network follows a strict hierarchical tree structure. The root represents the entire edge network, each tree node represents a lower level network, and each branch represents a section of prefix.
Thus, while we allow each lower level network to have multiple gateway routers (aka LGR), they must own and advertise one same subnet prefix. Only if we guarantee this, we can safely prune the destination address prefix off from a packet when it enters into this lower level network (or augment the source address with this prefix when a packet exits this lower level network).

In general, we assume one edge network is totally under a single operator. If not, then each operator should own a separate lower level network. In your scenario, node A and B should be in two different lower level networks, and they can communicate  using the approaches we laid out. Hopefully I understand your question correctly. If not, please feel free to elaborate it. Thanks!

Best regards,
Haoyu

From: Adnan Rashid <[email-masked]>
Sent: Thursday, November 11, 2021 4:07 PM
To: Haoyu Song <[email-masked]>
Cc: Uma Chunduri <[email-masked]>; Kerry Lynn <[email-masked]>; [email-masked]; Alexander Pelov <[email-masked]>; [email-masked]
Subject: Re: [6lo] [Int-area] Short Hierarchial IPv6 addresses

Hi Haoyu,

If yes then how can node A from Service Provider-A can communicate with node B from Service Provider-B and both are under the same border router or edge node?
Regards,

Adnan Rashid

On Thu, Nov 11, 2021, 20:10 Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Uma, those are really great use cases. I would like to include them in the new revisions. My feeling is that a universal scheme like this can benefit many applications/networks (some yet to be explored) and won't introduce unnecessary conflicts and burdens to well-developed HC techniques for 6loWPAN and LPWAN.
We look forward to collaborations and suggestions on where we should land this work. Please let me know if you are interested.

Best regards,
Haoyu

From: Uma Chunduri <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, November 11, 2021 9:08 AM
To: Haoyu Song <[email-masked]<mailto:[email-masked]>>
Cc: Kerry Lynn <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Alexander Pelov <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Int-area] [6lo] Short Hierarchial IPv6 addresses

regards!
--
Uma C.

Best regards,
Haoyu

Regards, Kerry

<snip>
_______________________________________________
Int-area mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fint-area&data=04%7C01%7Chaoyu.song%40futurewei.com%7C17610663cd644dcaafa408d9a5705f24%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637722724340866448%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bF%2BNjIh%2BUAzrpghrC1B3Ej1S%2BSbMRY16OC9MKb46V%2B4%3D&reserved=0>
_______________________________________________
6lo mailing list
[email-masked]<mailto:[email-masked]>
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%7C17610663cd644dcaafa408d9a5705f24%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637722724340876398%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2bSTwq6a3am%2B5D4iIAnFD0tqHpGJgd1TzqkuajUL%2Bzg%3D&reserved=0>

---

From: Adnan Rashid <[email-masked]>
Date: Fri, 12 Nov 2021 03:31:48 +0100

Hi Haoyu,

Your idea might be interesting, but I did not get it, still trying to
absorb it in the context of 6lo,  but I think it conflicts with other
exsiting 6lo standards. Just few comments

1- is it possible if you make a scenario in the next draft? Because you did
not answer about the ownership of border router. Can you check how PIOs are
shared in LLNs and how your idea deal with them? Note PIOs not a single PIO.
2- how you can define the scalability and flexibility, in context of a
multiple operators,  I think rfc6282 is far more simple and flexible.
3- you are just targeting the common prefix problem (which is bearable)
but putting alot of complexity in the LLN by making LGRs and new addressing
scheme.

A suggestion, read 6LoWPAN-ND and RPL may be after reading you can analyze
conflicts.

Regards,

Adnan Rashid

On Fri, Nov 12, 2021, 01:52 Haoyu Song <[email-masked]> wrote:

> Hi Adnan,
>
>
>
> Thank you for the question! In our architecture, the edge network follows
> a strict hierarchical tree structure. The root represents the entire edge
> network, each tree node represents a lower level network, and each branch
> represents a section of prefix.
>
> Thus, while we allow each lower level network to have multiple gateway
> routers (aka LGR), they must own and advertise one same subnet prefix. Only
> if we guarantee this, we can safely prune the destination address prefix
> off from a packet when it enters into this lower level network (or augment
> the source address with this prefix when a packet exits this lower level
> network).
>
>
>
> In general, we assume one edge network is totally under a single operator.
> If not, then each operator should own a separate lower level network. In
> your scenario, node A and B should be in two different lower level
> networks, and they can communicate  using the approaches we laid out.
> Hopefully I understand your question correctly. If not, please feel free to
> elaborate it. Thanks!
>
>
>
> Best regards,
>
> Haoyu
>
>
>
> *From:* Adnan Rashid <[email-masked]>
> *Sent:* Thursday, November 11, 2021 4:07 PM
> *Cc:* Uma Chunduri <[email-masked]>; Kerry Lynn <[email-masked]>;
> [email-masked]; Alexander Pelov <[email-masked]>; [email-masked]
> *Subject:* Re: [6lo] [Int-area] Short Hierarchial IPv6 addresses
>
>
>
> Hi Haoyu,
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fint-area&data=04%7C01%7Chaoyu.song%40futurewei.com%7C17610663cd644dcaafa408d9a5705f24%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637722724340866448%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bF%2BNjIh%2BUAzrpghrC1B3Ej1S%2BSbMRY16OC9MKb46V%2B4%3D&reserved=0>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6lo&data=04%7C01%7Chaoyu.song%40futurewei.com%7C17610663cd644dcaafa408d9a5705f24%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637722724340876398%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2bSTwq6a3am%2B5D4iIAnFD0tqHpGJgd1TzqkuajUL%2Bzg%3D&reserved=0>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 13 Nov 2021 18:48:25 -0500

While not really a supporter of the scheme, let me ask:

    > Consider if you have multi tenant network, then will your scheme work?

Please if you could explain what a multi-tenant network is in this context.
What is the trust relationship between the tenants and the operator?

Who is bringing the connectivity?  Who is providing the address space?
Do you expect each tenant to bring their own IPv6 prefix?
Consider BCP38.

    > node B from Service Provider-B and both are under the same border
    > router or edge node?

I think that it is okay if it doesn't work for mixed prefixes from multiple
providers.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 15 Nov 2021 10:51:16 +0000

Hello Haoyu

> From: Haoyu Song <[email-masked]>
> Sent: mardi 9 novembre 2021 22:25
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: RE: [6lo] Short Hierarchial IPv6 addresses
> 
> 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.
> 
> 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.

I can believe you on that. I'm sure you did an excellent work. 

> 
> 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 can believe that too.

> computing a source for resource/energy consumption? Is there any
> evaluation results on their impact? 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?

Small IoT devices may speak with a very narrow vocabulary may speak the compressed form for their transmission natively, and never see an uncompressed address.
The state and the work is on the router, and that's OK because it's powered and can be provisioned adequately automatically.
So they virtually have no cost associated. With RFC 8138, the Source Route header is optimized for forwarding in compressed form as well.

As you can see, it's very hard to position your solution (which is an architecture) vs. IPHC or SCHC (which are compression mechanisms). 

You can never win such a challenge on the basis of having short addresses. Because the compression mechanism can provide addresses of the same size as you do, and compress a lot more fields. Because that's their core business not a side effect. This is why 6lo is not the place for your work, sorry that INTAREA mislead you in that.

> understanding on the situation. Thanks!

No worries; you did great stuff. I'm just not convinced that this is the right place and the right time. 
45 years ago, or 45 years in the future, such a revolution might have been easier to consider than 25 years into IPv6 deployment. 
That's why I suggested talking to IAB.

Keep safe,

Pascal

> 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.
> 
> 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.
> 
> 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 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.
> >
> > 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".
> >
> 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.
> 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.
> >
> > 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.
> >
> router function will be greatly simplified, which is naturally
> beneficial for power, memory and energy.
> >
> > Best regards,
> > Haoyu
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatat
> racker.ietf.org%2Fdoc%2Fdraft-song-ship-
> edge%2F&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C95bdf07345f94c8
> 4ae6a08d9a3475653%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C63772034
> 9052868783%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=QI%2Bz2Aabf%2BiwCdcTcFV
> zRx%2BeOkOOO0iIvLFTqLznsiQ%3D&amp;reserved=0.
> > 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
> RFC6550 for routing, or is it that you don't need any routing due to
> your architecture?
> >
> > --

---

From: Haoyu Song <[email-masked]>
Date: Mon, 15 Nov 2021 16:55:11 +0000

Hi Pascal,

Thanks for  the advice! I would start to think about the other application scenarios and use cases that this work fit for.

Best regards,
Haoyu

-----Original Message-----
From: Pascal Thubert (pthubert) <[email-masked]> 
Sent: Monday, November 15, 2021 2:51 AM
To: Haoyu Song <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [6lo] Short Hierarchial IPv6 addresses

Hello Haoyu

> leads to lower router cost. So from the implementation point of view, 
> I have confidence on it.

I can believe that too.

> 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? 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?

Keep safe,

Pascal

> stateless one with 6282 and a more complex stateful with SCHC. Too 
> many standards kill the standard.
> 
> comparison going IPv6 looks a minor step. In any case this is not a 
> 6lo discussion, more an IAB one.
> 
> > Le 9 nov. 2021 à 00:58, Haoyu Song <[email-masked]> a 
> > écrit
> :
> >
> > Hi WG,
> >
> 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".
> >
> 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.
> some other header fields within the edge network can also be reduced 
> or simplified.
> >
> LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=QI%2Bz2Aabf%2BiwCdcTcF
> V zRx%2BeOkOOO0iIvLFTqLznsiQ%3D&amp;reserved=0.
> >> 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

---

From: Haoyu Song <[email-masked]>
Date: Mon, 15 Nov 2021 17:47:12 +0000

Hi Michael,

Thank you for the question! While I need more time to read the references provided by Adnan and think about the issue, a quick answer to your question is: in our current design, we require each sub network to have only a single prefix, otherwise the scheme won't work as currently described. So basically one operator will get an IPv6 prefix for an edge network so to own the address space for that prefix. Then in this space, the operator is free to partition it in the hierarchical way as described in the draft. 

Best regards,
Haoyu

-----Original Message-----
From: 6lo <[email-masked]> On Behalf Of Michael Richardson
Sent: Saturday, November 13, 2021 3:48 PM
To: Adnan Rashid <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [6lo] [Int-area] Short Hierarchial IPv6 addresses

    > node B from Service Provider-B and both are under the same border

I think that it is okay if it doesn't work for mixed prefixes from multiple providers.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-