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

[Carles Gomez Montenegro <[e-mail]>]

Hi Kiran,

Many thanks for your additional comments/responses.

Couple of questions, regarding the ‘radio and wireline' technologies that
you envision: do those technologies support multihop topologies? Also, if
you are considering specific technology examples, I am curious to know:
which would such technologies be?

Thanks in advance!

Cheers,

Carles (as WG participant)


<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>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Wed, 5 Apr 2023 at 01:44, Kiran Makhijani <[e-mail]> wrote:

> Thanks Carles. Follow up comments inline below with [KM].
>
>
>
> *From: *Carles Gomez Montenegro <[e-mail]>
> *Date: *Tuesday, April 4, 2023 at 9:51 AM
> *To: *Kiran Makhijani <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>, [e-mail] <[e-mail]>, lp-wan <
> [e-mail]>
> *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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo
>
>
>
> [image: 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>
>
>
>