Minutes IETF103: lpwan
minutes-103-lpwan-00

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 <pthubert@cisco.com>
                       Alexander Pelov <a@ackl.io>
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.