Re: [lp-wan] [6lo] I-D Action: draft-ietf-lpwan-architecture-02.txt

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

Hi Pascal,

Many thanks again for the discussion and your detailed insights!

Please find below my inline responses/comments:

> Hello Carles
>
>> -----Original Message-----
>>
>> Many thanks for updating the LPWAN architecture draft as per our
>> discussion!
>
> Yep; many thanks for your hints and comments, your steering in the right
> direction is really helpful.

:-)

>> In my opinion, the draft now provides the basis to generalize the use of
>> the
>> SCHC roles (Dev and App) or directions (Downlink and Uplink) for any
>> networking environment or topology.
>
> Cool
>
>> (And other drafts, such as draft-gomez-6lo-schc-15dot4, can now refer to
>> the
>> LPWAN architecture draft to this end.)
>>
>> I have two further comments:
>>
>> - In section 5.1, when talking about the P2P SCHC Instance, an
>> assumption
>> seems to be that there is one link between the two peers. However, there
>> could be several links (understood as radio hops) between the peers. For
>> the
>> sake of generality, perhaps the draft could also explicitly mention that
>> there can be a link **or a path** between the two peers, perhaps also
>> explicitly referring to 'mesh' or 'multihop' networks, which are now
>> covered
>> by the draft as well.
>
> We started that discussion but we're not there yet so I cannot turn the
> result in words.
> I'd say that there is the easy case and the hard case.
>
> * The easy case is RPL non-storing. RPL imposes a tunnel between the Root
> and the device and that can serve as a P2P transport. So we can do RFC
> 8138 (really efficient) for the outer tunnel and then SCHC inside. For
> this, we are almost all set, draft-gomez-6lo-schc-15dot4 could express the
> details on how we find that it is SCHC inside as opposed to RFC 6282 -
> willing to help here.

Great!

> Using the non-storing mode overlay, we're back to
> the hub and spoke and the Root is naturally Uplink. Note that if the
> destination is "external", which would probably be the case of a LFN
> (that's what Wi-SUN does), then RFC 9008 is clear that the Non-Storing
> mode signaling and tunneling applies as well, all set there too. And
> nothing prevents also using the tunnel in storing mode when there's SCHC
> inside, it's partially there anyway (e.g., for the root to add the RPI).

This sounds promising!

It would be nice to explore this approach.

> * The hard case is to make SCHC really multihop. It is not designed for
> that.

Agreed. This is a challenge, but hopefully we might be able to find/create
suitable techniques to support SCHC (or parts of SCHC) for multihop.

> E.g., fragmentation, either you reassemble at each hop and lose a
> lot of the benefit, or you need to consider extending SCHC for things like
> RFC 8931.

Actually, the current approach in draft-gomez-6lo-schc-15dot4 is to use
just the header compression part of SCHC, and keep using 6LoWPAN/6lo
fragmentation. In fact, I think that SCHC fragmentation is partly inspired
by RFC 8931, so both fragmentation approaches share some of the main
features anyway.

> Then there's the rules. If there are many and arbitrary
> destinations then it's hard for the parent to maintain a state for all the
> destinations of all the children and descendants.

Agreed. Route-over multihop with SCHC-compressed headers would be suitable
"as is" rather for small networks (low number of nodes), or if node memory
constraints are not too severe, and if context is relatively stable.

(Probably not suitable otherwise...)

> We're back to saying,
> let the root do that, but then, why not tunnel to it like in the case
> above?
>
> So we have to decide whether we model for the H&S overlay like RPL, or opt
> for a complicated change in SCHC.

I see!

Another area to consider is Mesh-Under, where I understand that there is
no particular challenge to use SCHC header compression for multihop
communication.

>> - The convention defined in 5.1 provides a default way to determine who
>> is
>> Dev and who is App (or what is understood by Uplink and Downlink).
>> My interpretation is that:
>>
>>    o If it is possible to know beforehand which one of the two peers is
>> Dev
>>      or App, a single Rule (also written beforehand) may suffice to
>> offer
>>      the best header compression performance for both communication
>>      directions (e.g., as in RFC 8724).
>>
>>    o In a less predictable scenario, where either one peer or the other
>>      could be the first to transmit (e.g., if they are peers in a strict
>>      sense), the convention still allows to determine the role of each
>>      device, but two Rules (one for each direction) may need to be
>> written
>>      to achieve the best header compression performance for both
>>      communication directions (one for each direction).
>>
>>   Perhaps some comment about this (i.e., the amount of context may be
>>   reduced if a scenario is predictable) could also be added to the
>> draft.
>
> Works for me, that was the intention. I like your wording. I'd like to
> elaborate in what you mean by " a single Rule (also written beforehand) ".
> Right now we say that the a priori knowledge (rule) is fully extrinsic to
> SCHC and has to do with the device (supports only 1 Instance), the network
> (the Hub is Uplink) or the supporting connection or tunnel (the node that
> starts it is Downlink). You seem to make it a SCHC Rule. Is that your
> meaning? If so, this may affect the model.

Yes, I agree with your text, and I think that is actually my meaning...

> Keep safe, sad we cannot continue this conversation in Philly since I'll
> be remote.

Well, I'll be remote too. :-)

Hopefully, we can find some way to progress online anyway...

Many thanks, Pascal!!

Carles



> Pascal
>
>>
>> Cheers,
>>
>> Carles
>>
>>
>> > A New Internet-Draft is available from the on-line Internet-Drafts
>> > directories.
>> > This draft is a work item of the IPv6 over Low Power Wide-Area
>> > Networks WG of the IETF.
>> >
>> >         Title           : LPWAN Static Context Header Compression
>> (SCHC)
>> > Architecture
>> >         Authors         : Alexander Pelov
>> >                           Pascal Thubert
>> >                           Ana Minaburo
>> >   Filename        : draft-ietf-lpwan-architecture-02.txt
>> >   Pages           : 14
>> >   Date            : 2022-06-30
>> >
>> > Abstract:
>> >    This document defines the LPWAN SCHC architecture.
>> >
>> >
>> > The IETF datatracker status page for this draft is:
>> > https://datatracker.ietf.org/doc/draft-ietf-lpwan-architecture/
>> >
>> > There is also an htmlized version available at:
>> > https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-architecture-02
>> >
>> > A diff from the previous version is available at:
>> > https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-architecture-02
>>
>>
>> _______________________________________________
>> lp-wan mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lp-wan
>
> _______________________________________________
> 6lo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo
>