Meeting : IETF 103 Tuesday, November 6, 2018 (+07) Time : 9:00-11:00 Bangkok time Tuesday Morning session I (2H00min) Location : Room Meeting 1, Marriott Marquis Queen's Park Hotel, Bangkok Agenda : https://datatracker.ietf.org/meeting/103/materials/agenda-103-lpwan Meeting Slides : https://datatracker.ietf.org/meeting/103/materials.html Etherpad : http://etherpad.tools.ietf.org/p/notes-ietf-103-lpwan?useMonospaceFont=true Meetecho : http://www.meetecho.com/ietf103/lpwan/ Audio stream : http://ietf103streaming.dnsalias.net/ietf/ietf1031.m3u Chairs : Pascal Thubert Alexander Pelov Responsible AD : Suresh Krishnan WG URLs : http://tools.ietf.org/wg/lpwan/ https://datatracker.ietf.org/wg/lpwan/ https://www.ietf.org/mailman/listinfo/lpwan Note takers ------ Ivaylo Carles Tomas Agenda ------ * [09:00] Administrivia [10min] o Note-Well, Scribes, Agenda Bashing o Status of drafts (WGLC / forthcoming WGLC) o Presenters: The Chairs This part is about the agenda, below there is the minutes part... :) * [09:10] draft-ietf-lpwan-ipv6-static-context-hc-17 [45min] o Presenters: Dominique Barthel, Laurent Toutain o Goal:relaunch WGLC * [09:55] draft-zuniga-lpwan-schc-over-sigfox-04 [10min] o Presenters: Juan-Carlos Zuniga o Goal: draft update and discussion about ACK-on-Error mode o call for adoption ? * [10:05] draft-petrov-lpwan-ipv6-schc-over-lorawan-02 [10min] o Presenters: Ivaylo Petrov o Goal: present advancement o call for adoption ? * [10:15] draft-authors-lpwan-schc-802154 [05min] o Presenters: Charlie Perkins o Goal: ? * [10:20] Rechartering [35min] o Discussion lead by the Chairs * [10:55] AOB (Charlie Perkins on IEEE) [05min] Minutes ----- * [09:00] Administrivia [10min] o Presenters: The Chairs Alex presents the Note Well. Minute takers (Ivaylo and Carles), Jabber scribes and related pointers. No adjustments required for the agenda. 5 interims since the last IETF WGLC successful on compression. Plan is to start WGLC on the fragmentation part after this IETF * [09:06] draft-ietf-lpwan-ipv6-static-context-hc-17 [45min] o Presenters: Dominique Barthel, Laurent Toutain DB presents the first items in this slot. DB presents an overview on the SCHC draft. There are 3 deliverables in the SCHC draft: SCHC compression, how to use SCHC to compress IP/UDP, and fragmentation. DB presents the progress since IETF102. New Ack-On-Error mode, reworked the text for some other parts as well. DB presents an overview of the changes, by sections. No change on compression/decompression. Main piece of work is fragmentation: restructured, and new ACK-on-Error mode. DB presents the result of the hackathon just before the IETF where work was done on openschc - a new micro-python implementation of SCHC. DB presents tickets status. Two new tickets since IETF 102. Now closed. DB overviews next steps. DB presents the fragmentation section changes. With explanations of new terminology - tiles, windows in more details. Section restructured: tools, message formats and algorithms. Pascal: Could we restate the description of tiles again as I am not sure it was well stated. DB: tiles don't always need to be of the same size (e.g. in No ACK). But in modes that support retransmission *and* variable MTU (currently, this is ACK-on-Error mode only), we do specify tiles need to be of the same size. Laurent presents new ACK-on-Error. Same original goal: reduce number of ACK messages. Only one ack is mandatory - the one at the end of transmission (for All-1 fragment). LT: last IETF there were issues raised, involving ambiguities. To solve ambiguities, solution is increasing the W field size, so that all tiles can be unambiguously identified. LT: example on W field size. 1280-byte packet and tile size of 6 bytes. FCN of 3 bits leads to W field size of 5 bits. Different rules can be used: e.g. one rule for larger packets (and large W field), and other rules for smaller packets (with smaller W field). LT: Due to relaxed synchronisation between sender and receiver in the new algorithm, State machines are simplified. Presents an example (related to the one that Dominique showed earlier). LT: Explains adaptation to different MTUs, achieved by the tiles size and sending a different number of tiles per L2 packet. LT: sending multiple small tiles does not generate more ACK traffic. LT: Explains in more details an example with lost fragment, plus when L2 MTU changes (in the example, the L2 MTU becomes smaller) between an original fragment transmission and retransmissions. LT: Explains the times when the ACK can be sent: could be at the end of a window or at the end of a packet. The sender and receiver need to know when the ACKs should be sent - this information needs to be present in the profiles. LT: Present the pros and cons: LT: Now the state machine is quite simple. ACK-on-Error can adapt the behavior. LT: Worst case is when there is one miss on each window. LT: we can now support variable L2 MTU. LT: We might have some extra padding. LT: it may need extra messages for technologies that need some uplink transmission to trigger downlink transmission (e.g. for downlink fragmented transmission) Pascal: thanks the authors for the work to solve the issue identified with ACK-on-Error Pascal: Some people from industry presented work done independently that has been 95% the same as Ack-On-Error. There is hope that there will be convergence. In class A in LoRa you need to pull the data (the same on Sigfox). The industry person is instead of pulling one after the other, you will get next fragment after each data-up with measurement data (for firmware update that is not pressing for example). The downlink fragmentation may last for days, might not be such a problem: the device just carries out its normal reporting, and downlink fragments will be triggered as a result whenever the uplink transmissions are performed. Alex: Thanks the authors as well for the huge work for improving readability and the improved Ack-On-Error. Hopeful for having SCHC in the core of the different technologies. Compression is rather clear, please do focus on the fragmentation part and provide feedback. The rechartering will be after we send the document to the IESG. Should happen before the 15th of December. Don't wait for the last moment. Suresh: if feedback comes by 15 Dec, then the document could be on telechat by end of January. If I receive it by 1 Dec, it can happen faster as during the holidays it will not be able to advance. Charlie: highly not trivial protocol design. Fragmentation in general is known to be a source of bugs. Don't solicit detailed review in a short time. Pascal: We ask to focus on fragmentation, so hopefully it will be doable. There are also implementations, which should help us find the bugs. * [09:43] draft-zuniga-lpwan-schc-over-sigfox-04 [10min] o Presenters: Juan-Carlos Zuniga JCZ presents -04 of SCHC over Sigfox. Based on SCHC rev -17. Issues from older ACK-on-Error (-16) have been addressed by SCHC -17. New -05 available as of yesterday. JCZ: fragmentation parameters optimized for a single byte of SCHC header overhead (up to 300 bytes in uplink). Possibility of larger packets with more overhead. JCZ: we need to rethink about downlink now with the new ACK-on-Error possibilities. In fact, initial thoughts on this matter are in the line with what Pascal just mentioned before about downlink, where fragments can be received over a long period and they can be ACKd (if needed) in a future. JCZ: no more issue of losing the All-0 or the SCHC ACK leading to an Abort (as presented in IETF 102). JCZ: MIC may not be needed for scenarios different from UDP/IPv6. Question for AD: would IESG see it as an issue if we mandate MIC for UDP and leave it open (optional) for other traffic? Suresh: I don't see an issue. If something comes up in the IESG discussion, I will let you know and handle it at the time. I am open to that if the WG is OK as well. As long as it is clear and there are interop implementations, it's fine. JCZ: That is a good feedback, we will need to take a pragmatic approach. Pascal: problem with UDP is the UDP checksum. In 6LoWPAN I did that. Convincing IESG to be allowed to elide UDP checksum. Pascal: There will be a problem compressing the UDP checksum, explaining when we can elide the checksum. Dominique: one technical point: the UDP checksum is elided at the compression sub-layer. The MIC is introduced at the fragmentation sub-layer. If we don't do fragmentation, we don't have a MIC. Therefore, the discussion on UDP checksum elision also depends on whether the packet needs to be fragmented or not. Pascal: MIC checked at reassembly, UDP checksum reconstructe at decompression. There is a gap between the two where data might get corrupted. Suresh: You are worried about bit correction? If that is the case, write down the failure situations and run it by Dominique and JCZ to comment. If something else is going to catch it, don't worry. If we have a paper trail, all the arguments are presented, it should be fine. Every AD reads the shepard's writeup, so put it there, with a pointer to the discussion in the ML with all the arguments. Don't anticipate a fight where there might not be one. Pascal: let's create a ticket proactively to be prepared on this topic JCZ: This seems like a rational approach. Alex: we have charter items on technology-dependent documents. You've been working on this document for a long time. Would you be willing to ask for WG adoption? JCZ: now that the baseline SCHC draft is pretty solid, we are confident that we can work out this technology specific draft. Pascal: anyone has a strong reason to oppose to the call for adoption? Suresh: are there milestiones for the tech-specific documents? Pascal: with the rechartering, we'll put all the milestones Suresh: I'm very happy with the progress the WG has made. Milestones connected to SCHC getting to the IESG. Pascal: the attention of the WG has been on SCHC itself, not on SCHC-over-foo drafts * [10:05] draft-petrov-lpwan-ipv6-schc-over-lorawan-02 [10min] o Presenters: Ivaylo Petrov IP: what happened at the IETF102 - new version of the draft. IP: overview of next steps. Currently looking at ACK-on-Error. It looks very nice. IP: ready for adoption? Alex: we'll be waiting to get the SCHC document, but everyone is invited to go over the document IP: any feedback will be appreciated * [10:05] draft-authors-lpwan-schc-802154 [05min] o Presenters: Charlie Perkins Charlie: September, a merged approach was decided for 802.15.4w Charlie: a "drafty merged draft" is available, to be reviewed Charlie: another work item is a coexistence document (mainly considering 802.11ah) JCZ: did all proposals get in? Charlie: not all details of all proposals Charlie: there is other relevant work in 802.15. Next time I'll present on that. Alex: are this people (involved in 15.4w) aware of IETF LPWAN WG? Charlie: Yes Charlie: regarding SCHC for 15.4w, we need to analyze whether new SCHC F/R is better Charlie: -01 probably before the next IETF Charlie: in -00, fragmentation at layer-2 is used. However, new SCHC frag could be better, so this needs to be analyzed Charlie: There might be other 15.4 PHY that could profit from that work Pascal: next we'll discuss about classes/profiles. You will need the data model that will be produced as a target of the rechartering. Might be good to have a homogeneous way to represent the parameters. Charlie: Alex: There might be different profiles per application? Charlie: There are different applications... Pascal: all the technologies we chartered to work on started without IP ("IP will never work there"). Here 4w assumes IP right from the beginning. It is a praise for this WG Pascal: we were charted for 4 technologies. There was not much activity related with Wi-SUN, now there's activity on 4w. Should we recharter for 4w instead of Wi-SUN? Charlie: We can discuss that next week during the IEEE meeting. Suresh: need to describe what is different between Wi-SUN and 4w Pascal: Do we need to respin the overview RFC? Suresh: I don't want to have a -bis document, but I want to know the differences. Pascal: We might be an overview kind of thing in the beginning of the technology specific document. Suresh: Yes, that could be fine. I do want the technology to be documented in an IETF document. So that everyone can know what this technology is about. Charlie: Is this in addition to what was in the overview? Suresh: I'm expecting some diff, could be in the 4w document. Alex: It is good to have a doc that states - this is how we do SCHC for this "application". The overview was a great document that is heavily cited. Pascal: When we started 6tish we started with only one technology. It is now supporting multiple ones. In lpwan we were ambitious and wanted to start with 4. Pascal: this is an example that, over time, we may want to recharter for new foos * [10:20] Rechartering [35min] o Discussion lead by the Chairs Pascal presents Charter 1. Had two items but the second item was a compound one consisting of a number of sub-items. Pascal: Some things are done (Informational "overview" document and UDP/IPv6), some things are still in progress for the second one. LT: We will need IPv4. Pascal: That will come later, I was presenting the chartering that was presented before. Pascal shows a "diff" between Charter I and proposed Charter II. The remaining items, after removing what has been done and considering proposed work items are: 1. CoAP, 2. Data models, 3. SCHC over foo, 4. OAM, 5. IPv4 ? Other ? [Minute taker's note: please refer to the full text in the slides] Suresh: Is there a candidate draft for 2? Pascal: draft - not exactly, work - yes. There are extra slides to answer that - at the end of the rechartering. Suresh: for 3, there will be four milestones, right? Pascal: yes Pascal: We are concerned that there might be inappropriate uses of CoAP (application layer). We have been discussing with CORE if our examples are well compressed, etc. The problem is mostly not in L2 layer, but applications. Suresh: will 4 include bootsrapping? Just to understand the scope Pascal: initially it's ping-like functionality and ICMP error. Suresh: IPv4 works, that's fine. Reluctant to spin-up IPv4-only work here. Not sure it's relevant to the IoT space. I want to see why this needs to get done. Pascal: We can have an informational - BTW IPv4 works. Suresh: Just put it in the SCHC draft if it is the case. LT: I don't think it works the way it is right now as it is slightly more complex. JCZ: 4 docs to interface with lower layers, not expected to depend on the higher layers. Pascal: Do you see work here? JCZ: No, just specification. Suresh: The more layers you put together, you can get a better compression. I don't want to have an LPWAN technology mandating/changing higher layer protocols. Pascal: We can have a document that discusses that even if we don't publish it. Suresh: that's something I'd also like to know (i.e. IPv4 being used in IoT space) Suresh: I'm happy that item 3 does not produce an "explosion" of CoAP for different techs JCZ: On ICMP - we want to focus on ping mainly (in one more) and we are referencing to some RFC. If we change the title, will that work? Suresh: Yes for the draft, the charter needs to indicater what you want to do Laurent: one missing point is security. E.g. how we deal with security mechanisms such as OSCORE. Especially to do management. Pascal: I'd like to see people working on an item before rechartering for that. We need to see people saying "we need it". Alex: I agree and as we have a heavy charter, I would prefer to have work done before we add that one. LT: But some things might be dependent on that. Alex: Then we will recharter. Suresh: I think security is included everywhere, so if you need to provide a new binding for DTLS, that's fine. One of the reason for OSCORE is that DTLS was not that efficient in some cases. I would like to see it and to be there. Suresh: I agree with Laurent this could be a blocking thing. Pascal: We are not removing security that is already there in IP/UDP, etc. If we don't have work that depends on this, this work might be better done elsewhere. But point taken. Laurent: IPv6 extensions could be used, since Mobile IP over LPWAN could be interesting. Pascal: do personal submissions, let's see interest. If it takes off, it could be included in a future rechartering Pascal: For IPv4, I want to see if the missing things are crutial. Alex: first 2 points seem straightforward. Point 3 needs adding that it's one document per tech (no "explosion at CoAP layer"...). For other documents pertaining to point 5, we need submissions, need to see interest, people working on the items, etc. Pascal: After we ship the SCHC document we were thinking to start the rechartering process (January). Suresh: January could be a good moment for the rechartering. Need to put it on a telechat, internal review, etc. Needs to be announced to other SDOs. Before the new IETF we could have a new charter. * [10:55] AOB [05min] Alex: thoughts on data model. SCHC Context: set of rules (for compression or fragmentation), each rule indicates a behavior. Alex: SCHC Endpoint Metadata. Other relevant info for two SCHC endpoints to interoperate. Alex: All that information is the SCHC profile. Until the hackathons it was not all that well understood what needs to be there. Now there is a much better understanding. This is work that needs to be done. We can use YANG for that as JSON is not that well structured. Alex: an option is to use YANG for the SCHC profile (comprising Context, Endpoint Metadata) Alex: We can serialize it using JSON/CBOR/XML/etc and use NETCONF, RESTCONF, CORECONF. Alex: we need to agree on structure (aligned with what's happening on Hackathons). Write a first YANG model. Then go get review by YANG doctors. Alex: The work can be quickly done. After the last call.