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 ]