Minutes IETF106: lpwan
minutes-106-lpwan-00

Meeting        :   IETF106 Tuesday, 19 November 2019
Venue          :   Raffles City Convention Center
Time           :   Afternoon Session II 1520-1650 (90min)
Location       :   Collyer
Chairs         :   Pascal Thubert pthubert@cisco.com
                   Alexander Pelov a@ackl.io
Responsible AD :   Suresh Krishnan
Live minutes   :   https://etherpad.tools.ietf.org/p/notes-ietf-106-lpwan
Live feeds     :   https://datatracker.ietf.org/meeting/agenda/

Other URLs     :   https://tools.ietf.org/wg/lpwan/
               :   https://datatracker.ietf.org/wg/lpwan/
               :   https://www.ietf.org/mailman/listinfo/lpwan
               :   https://bitbucket.org/lpwan

Minutes takers & Jabber
------

Minute takers: Laurent Toutain, Ivaylo Petrov, Eduardo Ingles
Jabber: Georgios

Agenda
------
(This part is for the agenda. The Minutes section is below)

*    [15:20] Administrivia (chairs)                                         
[10min]
    o    Note-Well, Scribes, Agenda Bashing
    o    Status of drafts

*    [15:30] Hackathon106 (Dominique Barthel)                                [
5min] *    [15:35] draft-ietf-lpwan-ipv6-static-context-hc-22 (Dominique
Barthel)  [20min] *    [15:55] draft-ietf-lpwan-schc-over-sigfox (Juan-Carlos
Zuniga)          [10min] *    [16:05] draft-ietf-lpwan-schc-over-lorawan
(Olivier Gimenez)            [15min] *    [16:20]
draft-ietf-lpwan-schc-yang-data-model (Laurent Toutain)         [10min] *   
[16:30] draft-ietf-lpwan-coap-static-context-hc (Laurent Toutain)       [10min]
*    [16:40] draft-barthel-lpwan-oam-schc (Dominique Barthel)               
[10min] *    [16:50] AOB, Adjourn                                              
     [ QS ]

Minutes
------

*    [15:20] Administrivia (chairs)                                         
[10min]
    o    Note-Well, Scribes, Agenda Bashing
    o    Status of drafts

Agenda Bashing: no changes
Alex: charter, be pround, all the milestones are been reached.
Suresh: The SCHC IPv6 UDP is about to be sent to the RFC EDITOR
- transform to XMLv3
CoAP I will get to it before the end of the year, that's what I think.
Pascal: This tells us that we are pretty ready to recharter.
Pascal: We will have a discussion later on the charter.

chairs: change item one which focuses on CoAP and rewrite in a more generic way
go to bar-over-schc.

Suresh: must be more specific on the technology and milestones.
Pascal: as for today we will not have an item for #1 (SCHC maintenanace
inclding new nar-over-SCHC), but if someone comes, we are ready (?) Suresh:
adding a milestone is between you and me, not IESG, so it's fine.

*    [15:30] Hackathon106 (Dominique Barthel)                                [
5min]

SCHC had a table at Hackathon,
University of Chili participate remotely.
Goal: open source implementation of SCHC
- merge branches on repo
- improve documentation
Juan Carlos, Guillaume and Diego worked on PySCHC

Next things to do:
    - specificatins are well understood, Inactivity timer on receiver
    - information for the Data Model
    - several implementation, Interop at next Hackathon

*    [15:35] draft-ietf-lpwan-ipv6-static-context-hc-22 (Dominique Barthel) 
[20min]

-22 passed IESG review
Dominique explains the architecture of the draft : 3 deliverables in 1 draft :
Generic compression, fragementation and description for UDP/IPv6 This draft is
linked to other drafts: CoAP, and L2. Dominuqe explains why there is a separate
draft for CoAP (some fields appears multiple times). No specific comments at
this draft from IESG telechat 3 IESG wanted discussion on the drafts

2 months to address comments, 10% of the draft has been updated.
Give inputs on that is coming up next :
    - push into RFC Editor queue (not today [as on the slide], but in the next
    few days) - ASCII art appearing tables to be replaced by real tables -
    comment from RFC editor as part of the new RFC publication process. - will
    fix tables and send to RFC Editor

Educate community about SCHC,
- georgios provides some tutorial materials

Demos of SCHC Usage
- DLMS/UDP/IPv6 over LoRaWAN
- CoAP header compression over LTE-m done in orange.
- SSH over lorawan done with cisco and acklio.

Implemenatations; (5 known , 1 tentative from RIOT)
OpenSCHC is mostly python3 based.
ACklio has 3 implementation(golang based, 2 (low-end and high-end device) C
based) Chile university based on micropython (the pycom variant)

Several scientific publications already existing - regarding general SCHC and
implementation-specific, both from the IETF-LPWAN and non-IETF-LPWAN community
(e.g. Univercity of Ghent, Belgium.) changes since -21:
    - fix a mistake in the Ack-Always description.
    - Appendix F has been changed, describes issues of running Ack-Always and
    Ack-on-Error over quasi-bidirectional links. States that it is schc-over-L2
    draft's responsability to give solution for making a quasi-bidir link bi
    directional for SCHC. The solution previously provided by appendix F may
    not be needed or appropriate for all the use cases. Hence, the draft will
    provide only a generic solution.
      we leave it to the SCHC-over-foo draft, to specify, if you need to do
      something for bidirectionality, what to do

- Security considerations remarks coming from IESG review leads to Major rewrite

*    [15:55] draft-ietf-lpwan-schc-over-sigfox (Juan-Carlos Zuniga)         
[10min]

Presents the draft and the updates, implementation from University of Chile

used google cloud

Architecture for PySCHC implementation:
    - SCHC Fragmenter Ack-on Error
    - SCHC Profile: Sigfox
    - Dev platform: PyCom
    - App platform: Google Cloud

fine tuning of the ACK mechanism for SigFox:
Using Sigfox fragement sequence number to determine the all-1 window.

In the Vancouver meeting, expecting to have a interop between various
technologies/implementations. Chile's team are expected to particpate in
person. Julien: So you rely on sigfox seq number. So does this mean that your
devices are transmitting only SCHC fragments? JCZ: ... Pascal: What happens if
a non-fragmented / non-SCHC packet is transmitted between two packets
(interleaving). The counter can increase. Julien: That is correct. We
considered this for LoRaWAN draft, but decided against it because of cases like
that. JCZ: We can discuss this offline whether we can solve this for everyone.
Alex: ... Maybe there could be one small draft that both drafts reference or
both drafts can specify. Pascal: wonder if it can be put in a profile; Alex: DO
you think the document will be ready to adopt SCHC base document changes by
next IETF. JCZ: I believe so, that is my intention. Alex: And check the data
model? JCZ: OK.

*    [16:05] draft-ietf-lpwan-schc-over-lorawan (Olivier Gimenez)           
[15min]

2 versions have been published,
unifying the Overhead size to 1 byte by using FPort.
- RuleId in FPort.
- DTAG is not used. Not an issue
- Tile size os 5 bytes
- Padding value is fixed to 0.
- Julien Catalano added as Editor (later reverted after a discussion during the
interim).

Tiles has been increased to reach the IPv6 minimal MTU
L: clarification question - on fport - you use the whole 8 bits for rule id
O: we use the whole fport for ruleId
L:
O: clarifation some values are reserved for LoRa(wan), so have the ruleId on 8
bits, but it goes from 1 to 223 ( 0 cannot be used , fportUP and fportDOWN are
reserved for fragmentation)

Pascal: I think you have a typo in the draft name
Olivier: I noticed it few minutes ago.

Olivier presenting multicasting.

Pascal: Do you have a practical use case for multicast?
Olivier: Yes, Firmware update in DLMS. They prefer not to use the methods in
LoRaWAN, but the DLMS one. Pascal: The reliable modes are on unicast only.
Pascal suggest discussing the multicast use cases in the mailing list - a
realiable one - as otherwise it will not be really useful. Julien: I don't want
to delay this document because of multicast, because it is not clear in our
minds. Pascal: We can have the multicast on as a second step. Olivier: agreed
JCZ: I am very interested in such multicast work, but I don't see the need to
delay any technology specific draft. Pascal: it is more, that we are going to
discuss rechartering

Pascal: We can start a discussion with Dave Thaler around IID.
Alex: do you think you are ready for working group last call for the next IETF?
Olivier: I think so

*    [16:20] draft-ietf-lpwan-coap-static-context-hc (Laurent Toutain)      
[10min]

Draft is ready - in IESG.
Presenting changes from v09 to v11.
Changed references because of the change of OSCORE

Alex: The draft is n Suresh hands.
Suresh: I want to get it to the IESG by Christmas.

*    [16:26] draft-ietf-lpwan-schc-yang-data-model (Laurent Toutain)        
[10min]

right now there is no draft, because the draft expired, but I will resubmit
[... interruption, switch of presentation...]
There is no real structure, just an explanation of the model,

Need feedback from implementors
Suggest to put on agenda for next interim
Alex emphasize it is important that the technology documents authors should
give feedback for this draft

*    [16:30] draft-barthel-lpwan-oam-schc (Dominique Barthel)               
[10min]

Dominique: reminder of the contents of the OAM SCHC draft, currently expired,
to be worked on again soon.

*    [16:40] AOB                                                    [ QS ]

Pascal: As we have some time, we would like to discuss the changes of the
proposed charter.
  1. maintenance (bar-over-SCHC)
  2. accept new work on reliable multicast (downstream) - only some of the
  nodes missed some fragments and recover. Do we agree with 1?
Suresh: I understand what it means, but I don;t think "bar-over-SCHC" is a good
name for that, Pascal: TO enable new upper layer protocols Suresh: Other than
CoAP. [Alex edits the charter proposal] Suresh: You can leave out Standard
track. Dominique: I don't quite like "upper layers protocols over SCHC",
because it sounds like you are changing your upper layer protocols ...
discussion on upper layer protocols compression, ultimately "SCHC mechanisms
for upper layer protocols [Alex re-edits the charter proposal] Ana (through
jabber): other Upper Layer than CoAP Suresh: This was my proposal as well, but
I am fine either way. Laurent: We might not need to say reliable as it would
suggest all device need to receive it, which might not be what we want. For me,
multicast alone would be better. Olivier: You don't necessarily want all the
fragments to be received if you use FEC on upper layer. Pascal: If you have FEC
on upper layer, we don't need to do anything. Olivier: We can use several
methods to use SCHC fragment delivery, so we might allow to lose fragments as
long as the packet is reliably delivered. Pascal writes a new corrected version
Suresh: Is the idea to have an ack mechanism or something else? Pascal: We
don't know. Suresh: Than maybe just say provide an improved mechanism for
increasing reliability of multicast fragments/packets. Pascal: Fragmented
multicast packet. ...: No one expects 100% reliability. RFC8740 (?) FEC at
transport layer ask for huming for point 2 (mechanism for reliability ...
multicast ...)? some humming heard. humm against? none heard will confirm on
mailing list. Carles GOmez: In Montreal we discussed about RTO. Question about
including previous RTO-related work Pascal: I didn't see enough activity
supporting you suggestion Alex: ~~interesting work, please continue, I did like
your work. We can include your idea in the next re-charter