* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Lpwan Status Pages

IPv6 over Low Power Wide-Area Networks (Active WG)
Int Area: Suresh Krishnan, Terry Manderson | 2016-Oct-14 —  

IETF-103 lpwan minutes

Session 2018-11-06 0900-1100: Meeting 1 - Audio stream - lpwan chatroom


minutes-103-lpwan-00 minute

          Meeting        :   IETF 103 Tuesday, November 6, 2018 (+07)
          Time           :   9:00-11:00 Bangkok time Tuesday Morning session I
          Location       :   Room Meeting 1, Marriott Marquis Queen's Park Hotel,
          Agenda         :
          Meeting Slides :   https://datatracker.ietf.org/meeting/103/materials.html
          Etherpad       :
          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/
          Note takers
          *    [09:00] Administrivia
              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
              o    Presenters: Dominique Barthel, Laurent Toutain
              o    Goal:relaunch WGLC
          *    [09:55] draft-zuniga-lpwan-schc-over-sigfox-04
              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
              o    Presenters: Ivaylo Petrov
              o    Goal: present advancement
              o          call for adoption ?
          *    [10:15] draft-authors-lpwan-schc-802154
              o    Presenters: Charlie Perkins
              o    Goal: ?
          *    [10:20] Rechartering
              o    Discussion lead by the Chairs
          *    [10:55] AOB (Charlie Perkins on IEEE)
          *    [09:00] Administrivia
              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
              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
          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
              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
          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
              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
              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
          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.
          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
          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
          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
              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
          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,
          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.

Generated from PyHt script /wg/lpwan/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -