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