Re: [lp-wan] [6lo] Transmission of SCHC-compressed packets (draft-ietf-6lo-schc-15dot4)

Thanks Carles. Follow up comments inline below with [KM].

From: Carles Gomez Montenegro <carles.gomez@upc.edu>
Date: Tuesday, April 4, 2023 at 9:51 AM
To: Kiran Makhijani <kiran.ietf@gmail.com>
Cc: 6lo@ietf.org <6lo@ietf.org>, schc@ietf.org <schc@ietf.org>, lp-wan <lp-wan@ietf.org>
Subject: Re: [6lo] Transmission of SCHC-compressed packets (draft-ietf-6lo-schc-15dot4)
(Resending, since there was a typo in one of the email addresses... Apologies for that!)

Carles

----------------

Hi Kiran,

(Adding LPWAN/SCHC in CC' as well...)

Many thanks for your message.

Please find below my inline responses/comments:

On Tue, 4 Apr 2023 at 07:20, Kiran Makhijani <kiran.ietf@gmail.com<mailto:kiran.ietf@gmail.com>> wrote:
Hello, Carles, and other authors
Thank you for presenting this work and presentation last Friday. I am repeating here what we discussed in the hallway after the meeting.

Great, thanks!

I am wondering is it possible to generalize the spec for any layer 2 not just 15dot4, since there will be more commonalities than differences as we consider nuances over different types of media. I work in industrial IoT which is a mix of radio and wireless IoT devices and I can see that SCHC can be beneficial for both type of field devices (both are resource constrained). What do you think?

I think that it is indeed possible to use SCHC (or, at least, SCHC components, such as the header compression part) over many different Layer 2 (L2) technologies (including, but not limited to the LPWAN space for which SCHC was originally designed). In order to enable that, I understand that there are at least two options: i) producing one SCHC-over-foo specification per L2 technology (which is the current approach in draft-ietf-6lo-schc-15dot4); and ii) producing a generic specification plus one L2 technology-specific document describing how to apply the generic specification for a given target L2 technology. I understand that you would be interested in this second option.

[KM] Yes, I would like to see second option with a generic specification. I also had typo above - wanted to say ‘radio and wireline IoT devices’.

(Note: interestingly, 6LoWPAN was originally designed to efficiently support IPv6 over IEEE 802.15.4, and then the 6Lo WG reused/adapted 6LoWPAN to support IPv6 over several other L2 technologies, producing one corresponding specification for each L2 technology; this is similar to the first option mentioned above. However, the LPWAN WG work has followed the second option above, since SCHC is generic and then its use over a particular L2 technology is enabled by means of a technology-specific document.)

When we started to work in our current draft (draft-ietf-6lo-schc-15dot4), we also considered the two options. At that moment, the first option seemed to be more focused, and there was no explicit interest yet from other technologies, so probably there was not enough motivation for a generic specification. Perhaps, at this moment, the picture may be starting to change...
[KM] As I said, it is really useful to produce generic (or common spec). So far, I did not see too many dependencies on 802.15.4. I think we should go with generic approach.

If there is enough interest, we might consider producing a generalized version of draft-ietf-6lo-schc-15dot, and then there would need to be another document specifying how to use the generalized functionality over IEEE 802.15.4 or any other target L2 technology. However, we may also need to consider the additional complexity of such a process (perhaps the 6Lo and SCHC chairs and ADs may have some opinion in this regard...).
[KM] sounds good.
Any thoughts or preferences from the 6lo and SCHC WGs?
[KM] I am ok whichever group it goes to – but yes, logically SCHC makes sense as Pascal mentioned.

If you accept that then, it will be possible to pick one approach. I felt that right now 4 options are too many and a bit confusing. Perhaps, we can evaluate them to produce requirements, then see if one solution can satisfy those? To be honest I still have not finished reading the entire document so must have misunderstood your presentation, but will be happy to help improve it, however possible.

I understand that you refer to the 4 options (currently, "approaches") for multihop communication. Yes, we are still in relatively initial stages of the draft, exploring different approaches and their pros/cons. I also think that the number of approaches would need to be lower.

In my opinion, we should define at least two "approaches": one for mesh under, and at least one for route-over. Regarding the latter, initially there was only the "Straightforward" approach, which offers the lowest header overhead but requires all nodes to store all the Rules in use in the network. For the sake of scalability, the "Tunneled, RPL-based" approach was added, so that 6LRs do not have to store the Rules. However, we just added in -01 the "Pointer-based" approach, which is also scalable, but with lower header overhead. We are already considering modifications that can address issues in the existing "approaches". Once things become a bit more stable, we might simplify the specification, perhaps by removing or combining one or more "approaches".

[km] Yes, I like the suggestions on a procedure each for mesh under and router-over. My sense was that pointer-based approach was quite inclusive and scalable.
Thanks,
Kiran

Cheers,

Carles (as WG participant)

Thanks
Kiran
_______________________________________________
6lo mailing list
6lo@ietf.org<mailto:6lo@ietf.org>
https://www.ietf.org/mailman/listinfo/6lo

[Image removed by sender.]<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Libre de virus.www.avg.com<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>