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

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Carles

Many thanks! Will you present your draft at the IETF 114 LPWAN meeting this time ? - I just posted a call for agenda item.
Anyway we'll chat at the WG meeting during the slot on architecture. Also, for mesh under, the connection can the pair of MACs (=> only one Instance per pair), but there is no implicit sense of direction. So it's not per se a solution.
I'll need to understand better how you want to install / use that " single Rule (also written beforehand) ".

Take care,

Pascal

> -----Original Message-----
> From: Carles Gomez Montenegro <[e-mail]>
> Sent: jeudi 7 juillet 2022 12:59
> To: Pascal Thubert (pthubert) <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [6lo] [lp-wan] I-D Action: draft-ietf-lpwan-architecture-02.txt
> 
> 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
> >
>