Minutes interim-2020-lpwan-10: Tue 16:00
minutes-interim-2020-lpwan-10-202006161600-02

Connection details
------------------
• Date: 7-8am US Pacific DST, 4pm CEST:
https://www.worldtimebuddy.com/?qm=1&lid=100,12,5392171,1850147&h=100&date=2020-06-16&sln=14-15

JOIN WEBEX MEETING
https://ietf.webex.com/ietf/j.php?MTID=m45866408ff12537a6fbaefaa37cf97a0
Meeting number (access code): 619 208 505

Meeting password: tG99jRSJgJ9

JOIN BY PHONE
1-650-479-3208 Call-in toll number (US/Canada)
Tap here to call (mobile phones only, hosts not supported):
tel:%2B1-650-479-3208,,*01*619208505%23%23*01*

JOIN FROM A VIDEO SYSTEM OR APPLICATION
Dial sip:619208505@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting number.

Join using Microsoft Lync or Microsoft Skype for Business
Dial sip:619208505.ietf@lync.webex.com

Etherpad:
https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-lpwan-10-lpwan?useMonospaceFont=true

Agenda
------

The general agenda for all meetings is as follows:

[16:05] Administrivia                [ 5min]
    o    Note-Well, Scribes, Agenda Bashing
    o    WG Status

[16:10] SCHC over LoRaWAN                  [40min]
[16:50] SCHC over PPP                      [10min]
[xx:xx] AOB                                [ QS ]

Attendees
---------

    * Ana Minaburo, Acklio
    * Pascal Thubert, Cisco
    * Alexander Pelov, Acklio
    * Diego Dujovne, UDP
    * Ivaylo Petrov, Acklio
    * Laurent Toutain, IMT Atlantique
    * Julien Catalano, Kerlink
    * Sean Turner, sn3rd
    * Éric Vyncke, Cisco
    * Carles Gomez, Universitat Politecnica de Catalunya
    * Dominique Barthel, Orange
    * J Lecoeuvre
    * Olivier Gimenez, Semtech
    * Arunprabhu Kandasamy, Acklio
    * Juan Carlos Zuniga, Sigfox

Past Attendees for cc
------------------
    * Watson Ladd, Cloudflare
    * A Paventhan, ERNET India
    * Vincent Audebert, EDF
    * Sergio Aguilar
    * Ricardo Andreasen

Minutes
-------

The general agenda for all meetings is as follows:

[16:05] Administrivia                [ 5min]
    o    Note-Well, Scribes, Agenda Bashing
    o    WG Status

Alex presenting Note-Well.
Minutes from the last meeting are validated.
Agenda bashing - done, no changes.
EV: CoAP draft- Meeting tomorrow with Eric and authors to discuss Magnus'
point, and then we can go forward with the IESG evaluation of the draft.

[16:10] SCHC over LoRaWAN     (Olivier)             [40min]

Olivier Gimenez presents

    * On downlink retransmission timer

    * Explains the Class A operation, needs an uplink to get a downlink

    * need an uplink to get an ack request on retransmission timer time out

    * proposal to add an heartbeat to open an Rx window

     (helps schc gw to initiate communication and also send schc_ack_req)

    Q: what goes in the heartbeat message?

     send uplink (command control?) on special port.
   * empty payload or say "any message with command control" (could empty or
   not) * Question to audience: anybody opposed or in favour of this proposal:
   1) sending a command control as a heatbeat? 2) free to be empty or not empty?

     JCZ: same issue applies to sigfox. In favor. Maybe we should not be strict
     what the uplink message will be.

Ana: need something to determine but this is implementation. proposed not to
limit to heartbeat. Laurent: like the proposal a lot. Concur with Ana and
JCZ.It can be defined as a rule. Could be made more generic than Command
Control. Suggestion: link it to state machine (of the application?), rather
than free-running heatbeat? wasted resource. Empty message would not impose
periodic behaviour. Ivo: not having periodicity makes it more difficult for
application to understand how things work. Laurent: would this be different
timer other than one defined in the schc ? Julien: wonder if not re-inventing a
MAC mechanism. Similar to Class-B (albeit Class B is much shorter than 12
hours). Pascal: linked to application. Dominique: two proposals on the table
  i. like an hb creates an opportunity for downlink. Solves two problems in one
  go. May look like a MAC algorithm. ii.if in the sm expecting a schc_ack_req,
  then it sends something to trigger downlink opportunity.
Dominique: in favor of first proposal. Because cleaner model for the
application. JCZ: In sigfox we don't have class B, so this should be solved
ideally by sending some other. The hb mechanism should be considered as
fallback. Oliver: hb mechanism proposal is to run forever. Pascal: class B
neveer sends heartbeat up. Saves energy. Oliiver: not quite. Period is much
longer. Laurent: can't we use fpending bit in the lorawan layer for this
purpose? Olivier: No, it is not related. Pascal: I am not against the HB, but
maybe not all applications would need it and it should be possible to disable
it. JCZ: should be here, but see it more as a recommendation, as opposed to a
MUST in the specification. Pascal: We had something like that in RIPL where we
mandated to have a mechanism to open a downlink slot and proposed a possible
solution, but implementations could use something else instead as long as they
have such a mechanism. Alex: How about - let's say that the device needs to
ensure that there is an uplink each X hours (48 let's say). If there is no
uplinks, we can have a rule that sends an UDP. Alex: UDP port 9, discard
service. RFC863 Alex: I like the whole idea and I think this is something that
we need to develop, but what worries me is that this might slow down
significantly the draft development. Olivier: That is why I proposed empty
uplink, which is simple to define. Dominique: We need by-directional
communication for AoE and AA. Julien: 2 hb message per day would be a killing
factor for smart metering use cases that is aimed at running for 20years.
Dominique: you can change the periodicity to something much bigger if this is
not necessary. Laurent: hb name is confusing. it expects an application to say
that it is alive. propose to go back to sending packet using empty rule. JCZ: I
agree that imposing strict hours is not good. Olivier: not the current proposal
laurent: dont call it heartbeat JCZ: should be a recommendation, not a MUST.
Olivier: time interval is recommended only. Laurent: Only the name worries me,
the concept is good. Pascal: "POLL" is used in HDLC. Alex: would love to be
able to apply RFC8724 without re-inventing new mechanism. "empty rule" or UDP
Port 9 would achieve the goal. Alex: should express the question as "provide
Olivier: Could we send compressed uplink during the downlink fragmentation.
Julien: not multiplexed fragmentation session. It could be a problem if the
specification doesn't allow multiplexing different applications. Olivier: No,
only multiplexing fragmentation is restricted. Julien: MAC-level empty frame is
simpler, better Julien: polling is good, regular timing or exponential
back-off? Olivier: exponential backoff will help question 2.2, but not 2.1,
since Inactivity timer is constant. Pascal: max period, even with exponential
backoff. Alex: adding new mechanism is going to take time to design/review.
Weigh the benefits vs cost. Oliver: seems every one agrees with concept of
polling. Requests for application to be able to disable it when no frag session
up on-going. Laurent: it is triggered by the state machine. Olivier: Laurent:
want to solve 2.1 and 2.2 differently (more optimized). Polling done by using
an empty rule. Alex: propose to say "under control of application, MUST send an
uplink Olivier: Personally I am OK to say that implementations should send
uplink. Laurent: It is in the fragmentation that we could know the timer. On
the application level we can not mandate anything in an RFC Olivier: Can we
allow users not to support downlinks. Julien: We disable the downlinks on the
application - it is like putting a strict firewall Alex: Maybe we should put
some mechanism in place with big default and allow implementers to change it as
needed. Julien: cannot mandate the mechanism. Olivier: It seems that the
concensus is to have polling mechanism that can be disabled by the application.
While having the fragmentation session, we have the polling and we can not
disable it. Alex: I don't like the new empty rule as that will add a new
concept. Julien: an empty mac packet at the lorawan layer is sufficent. Pascal:
Discussion to be continued on the ML. [16:57] SCHC over PPP                    
 [10min] Pascal: defined profile for PPP Pascal: PPP is a profile without
fragmentation Laurent: Why do you put padding at the end of the residue?
Discussed several time, padding is at the end of the frame. Alex: About the
Adoption at LPWAN, check with Eric if falling under the Charter. Eric: Sure,
need to validate this point. [xx:xx] AOB                                [ QS ]