Minutes IETF105: lpwan
minutes-105-lpwan-00

Meeting        :   IETF105 Friday July 26th, 2019
Venue          :   Fairmont The Queen Elizabeth Montreal
Time           :   10:00 to 12:00, during Morning session I (120 minutes)
Location       :   Van Horne,
https://datatracker.ietf.org/meeting/105/floor-plan#ground-floor Chairs        
:   Pascal Thubert pthubert@cisco.com
                   Alexander Pelov a@ackl.io (remote)
                   Dominique Barthel dominique.barthel@orange.com (stand-in,
                   thank you!)
Responsible AD :   Suresh Krishnan
Live minutes   :   https://etherpad.tools.ietf.org/p/notes-ietf-105-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
------

Ana Minaburo, Laurent Toutain, Ivaylo

Agenda
------
(This part is for the agenda. The Minutes section is below)

*    [10:00] Administrivia (chairs)                                  [10min]
    o    Note-Well, Scribes, Agenda Bashing
    o    Status of drafts

*    [10:10] draft-ietf-lpwan-ipv6-static-context-hc (Dominique)     [15min]
*    [10:25] draft-ietf-lpwan-schc-over-sigfox (Juan-Carlos)         [ 5min]
*    [10:30] draft-ietf-lpwan-schc-over-lorawan (Ivaylo)             [25min]
*    [10:55] draft-toutain-lpwan-schc-yang-data-model (Laurent)      [15min]
*    [11:10] draft-ietf-lpwan-coap-static-context-hc (Laurent)       [10min]
*    [11:20] draft-barthel-lpwan-oam-schc (Dominique)                [5min]
*    [11:25] draft-gomez-lpwan-rto-considerations (Carles)           [10min]
*    [11:35] Status on IEEE 802.15.4 (Charlie / Bob's slide)         [10min]
*    [11:45] Rechartering status (Chairs and A-D)                    [15min]
*    [11:xx] AOB, Adjourn                                            [ QS ]

Minutes
------

[10:00] Administrivia (chairs)                                  [10min]
    o    Note-Well, Scribes, Agenda Bashing
    o    Status of drafts

* If there is an IPR please let us know, you can talk privately with the chairs
* Note Well is displayed
* Please verify the minutes
* Agenda bashing,
  - short presentation of new SCHC implementation from Chile , called PySCHC
  - Lots of work on LoRaWAN, allocate a significant portion of time to allow
  for discussions - No news from Charlie, probably no IEEE update this time?
* Main WI is completed
* CoAP will be sent on November, Laurent agrees to] keep the date, we need to
discuss with Suresh * No bashing so Agenda is accepted

[10:10] draft-ietf-lpwan-ipv6-static-context-hc (Dominique)     [15min]
* Dominique presents the status of SCHC ver 21
* What is about?
* 3 deliverables in one draft: Generic compression engine, Fragmentation
protocol, Spec for simple IPv6/UDP compression
  - The Section 7 is a general description of the SCHC compression, that can be
  used for any protocol - The section 8 specifies the fragmentation protocol,
  with 3 modes, and the details of the different modes - Section 10 applies the
  SCHC header compression over the IPv6 and UDP protocols.
* other drafts specify compression of upper layers, like
draft-ietf-lpwan-coap-static-context-hc  from IPv6 to OSCORE. * other drafts
specify fragmentation over lower layers, like Sigfox and LoRaWAN. * another
draft will define a representation of the Rules, this part is not in this draft
* Since IETF104?
  - Feedback has arrived, updated draft
  - IETF LC has expired without comment
  - draft in "waiting for review" state
Suresh: do you have more edits to do?
Dominique: As of today, there are no pending updates
Suresh: Then will launch IESG review. Some people upload a draft after it has
been distributed to some reviewers and then some people have read one version,
others other and it's not good
  - Expected 27th (or was it 22nd?) of August to be on the telechat
  - Telecharter is done automatically after the last reviews are done
  - Anyone can be on the telechat as an observer
  - Suresh send the Webex for the ones that want to come
Dominique: I would like to join as a listener

* Hackathon 105 report
  - Produced documentation on Open SCHC: improvements to existing doc, new
  tutorial - Merging branches to integrate Compression and Fragmentation,
  improved fragmentation

* Next
  - Communicate about SCHC, we'll put together a tutorial
  - All the groups/SODs that are interested can ask us
  - There is a lot of groups interesting:
    -CoAP compression over LTE-m
    -CoAP over LoRAWAN
    -DLMS over Lorawan transmission. Schc is evaluated at the LoRa Alliance for
    DLMS - SCHC for IPsec (Diet-IPsec)
* implementations of SCHC: Acklio, OpenSCHC.net, Univ de Chile, RiOT (intended,
not done)

* Sandra Cespedes:
-  work from a Master student, implemtation of SCHC over LoRaWAN.
- LoPy connected to the TTN, SCHC core is on AWS. Implemented in Lambda
function. - The implementation is done in modules: C/D, F/A, parser, Rule
Manager - Rules are in a dictionary - Tested Uplink for the compression,
downlink still to be tested - Not implemented for now: LSB and mapping-sent CDA
- To finish F/R

Laurent: We can try to interop, Do you implement CoAP?
Sandra: No only, UDP. Source code will be made available and we will send a
mail to inform Ivaylo: did you look at SCHC over LoRaWAN? Yes. Pascal: Your
feedback is very important to us, to know if there is something missing or
unclear in the specification. Dominique: I understand Rodrigo will be at the
next Hackathon, maybe we can plan for an interop? Pascal: Needs for common
representation of rules Rodrigo: In this moment, the representation of the
rules is through a Python dictionary Rodrigo: How can we prepare an
interoperability test before the hackathon?

[10:24] draft-ietf-lpwan-schc-over-sigfox (Juan-Carlos)         [ 5min]

* Quick update, optimization of the SCHC parameters
* Optimize fragmentation parameters for the payload size of the UL and DL
* 2 uplink scenarios, now optimized for minimum overhead
* the second one is for the payloads from 300 to 2000 bytes
* 300 bytes confortable with a single DL message
* We will keep working to finish the implementation and optimize the protocol

[10:27] draft-ietf-lpwan-schc-over-lorawan (Ivaylo)             [25min]
* reminds of Lorawan specifications: class A most constrained, class B
sometimes DL, and Class C DL any time
  - SCHC timers differ accordingly across different classes
* confirmed and unconfirmed messages
* Multiple implementation of network servers, not all implement all the
properties of the MAC layer. * FOpts and FPort will be explained in following
slides. * Difference in regulation in every country, optimal radio conditions
are different in many parts of the world, to be taken into account for the SCHC
fragmentation * Different fields of the Lorawan packets
  - They are use for control of the radio link
  - FOpts is variable length, can be up to 15 Bytes long, FPort is 1 Byte long
* Since Prague document was adopted by the WG
* Whe have received may feedbacks for all, thank for your ideas and
recommendations * We update the terminology and figures of the base document *
UL fragmentation will be ACK-on-error * DL fragmentation we will use the
ack-always * More details about the Lorawan terminology * Regarding SCHC
Fragmentation:
  - use of FPort value to differentiate between modes.
  - The FPortUP value has been split in 2: one optimal for smaller packets
  fragmentation and the other for the requirements of IPv6 packets

Julien: FPort dedicated to fragmentation or for compression ?
Ivo: One of the Fport has the possibility to be used also for compression,
FPortUpDefault, and the FportUpShort is only for fragmentation because it does
not have space for Rule ID. The FPortUpDefault has space for some Rule IDs
Julien: it is confusing, to have FPort for fragmentation and compression. Ivo:
We can consider, it seems interesting, we can discuss. Dominique: The text is
confusing, relationship between FPort and Rule ID. Currently, I read the doc as
you have 3 rule sets, which are selected by the FPort value. FPortUpShort
designes a rule set with only one rule (therefore 0 bits for Rule ID). The
other way of describing the same behaviour could be to say thay the RuleID
field overlaps with the FPort byte of LoRaWAN. This way, you have only one Rule
set and variable length Rule IDs. Dominique: Pick one of the two description,
either is fine. But describe it more clearly. Pascal: Could you propose some
text? Dominique: I have already done so on the mailing list, discussion is
on-going with Olivier, will work again with him. Rodrigo on Jabber: You cannot
access the FPort in some platforms Olivier (via Meetecho): You can access the
FPort, if the device is Lorawan certified, I can point you to the documentation.

* Tile size is 3 bytes, this was chosen to optimize for some region where the
min payload is 11 Bytes.

Laurent: One precision, the size of 3 byte is for FPortUpShort or only
fragmentation Ivo: only fragmentation, we have minor comments on this from the
WG

* Example of the Payload fragmentation
Julien: SCHC  DTAG 1 bit, is it useful or not? may I eliminate?
Laurent: DTAG has 2 functions, one is to allow to send multiple fragmented
packets in parallel and the second at the end to not lose the context while
waiting for the ack. Julien: may I merge both? Laurent: yes Dominique: I was
surprised to see DTag here, because you also say you don't send multiple
fragmented packets simultaneously. I understand the DTag bit is here for extra
safety, but it is not mandatory. Ivo: I think is just for safety Olivier (via
Meetecho): to detect a session change, DTag bit makes it easier. But not need
for two fragmentations at the same time.

* Format of the Acknowledgement,
* Version 02, has fixed changes, figures, we have added examples

Julien: Compression residues are not byte aligned, what was the rationale?
Dominique: The decision for the residue to be bits is for Compression
efficiency. If there's only one bit of entropy in the message, we send only one
bit. Question was, do we pad after the residues or after the payload. Padding
after the residue would mean to pad twice in case of fragmentation. We decided
to pad only once. Pascal: There is a discussion on the ML about that, you can
go and look at it and come again to the ML if there are questions Julien: For
the implementers, could be difficult to shift many bytes. Dominique: general
assumption that computation is free compared to cost of sending/receiving over
the radio.

* Upcoming changes:
   - remove restriction in the ruleID size. should be necessary for some
   appliations. Implementors can decide what is the best. - FPending bit tells
   the device that they is more data in the NGW, but not used it since some
   implementations do not use it. - does not make sense to send confirmed
   message, can be redundant

* Tile of 3 bytes, after some experimentation, this size is the best
optimization to fit all Lorawan MTUs * Also to not increase the size of the
bitmap * Remaining: finalize the IID computation * And we will be happy to
receive more reviews

Julien: Can we use someting else than the CRC32, since other MIC algorithms are
available in LoRaWAN? Dominique: Is you question about implementing another way
of computing the CRC or do something else than using MIC? Julien: Implement
another computation. Dominique: Yes, the generic SCHC draft allows to use
another algorithm to compute the CRC.

Ivo: can WGLC be sent issued?
Pascal: chairs are happy, if there is no other question, to go for a WCLC.
Pascal: who would review the draft?
Volunteer reviewers:
- Georgious
- Dominique

Sergio (via Meetecho): is it possible to have the tile size change depending on
the MTU? Dominique: in ACK-on-Error, the Tile is a fixed size, it is the
quantum of data that is transferred, otherwise ACK-on-error does not work. On
ACK-on-error you need to resend the message you have sent, if MTU is smaller,
the payload is smaller, the data has to find its place in the reassembly
buffer. The tile is the quantum of data that you pave the reassembly buffer
with. Laurent: Tile of 3 bytes is a US limitaiton, can it be released in other
regions? Olivier (via Meetecho): For simplification, we made it the same value
whatever the local regulation. In the futre we will have devices going and
forwarding from one country and another and we do not want complexity on that.

Edgar (Jabber): can the Tile size be negotiated by the protocol ?
Ivo: from the bootstrap on, it is needed.

Julien: could one have different tiles sizes in different rules?
Dominique: If you want to achieve variable tile sizes, you could either have,
as suggested by Julien, multiple rules in same rule set (with different tile
sizes), or, as part of the provisioning, you can install a new context with
another tile size. Pascal: is tile size 3 a MUST in the draft? Ivo/Olivier: It
is a MUST, Pascal: if you release this MUST later, you can write another draft
to say that it now becomes configurable.

[11:01] draft-toutain-lpwan-schc-yang-data-model (Laurent)      [15min]

- We have a very abstract mode to represent
- Christian also said we can use hash in the rule
- We need to study the way to represent the model
- We are reaching our limits on yang
- We request a yang doctor
Suresh: We did not have a yang doctor answer, nothing happens, so I will see
with Mehmet to get a yang doctor directly

- Carsten proposes to have CoAP options designated using the number, and not
the name, as a new option will change all the space - The idea is not to do any
translation - The Sid space could be very huge? do we need it for another
protocol we need to compress

Pascal: You do not need to resolve the 65000 now,
Ivo: You can have until 1 thousand now
Pascal: If you see more than X go somewhere else, if you have more ranges keep
away and see the next numbers

[11:07] draft-ietf-lpwan-coap-static-context-hc (Laurent)       [10min]

- Go from V7 to V9,
- we receive reviews from CORE and LPWAN
- We receive comment from Christian to include the hash in both part to avoid
confusion when error and have a bad behavior, - We need the data model before
do it, and of course we can do it. I do not see how to do it right now. - V8
text edition, nothing new - V9 addressed comment about possible CORE
ossification, and the evolution of the protocol, that this can not block the
SCHC compression - This will not block the compression because we have the way
to manipulate this new versions, we have added some text about this

- WGLC has finished?
- Reviews have been received and modifications have been done
Pascal: Does somebody want to be Shepherd? maybe Alex, Ivo?
Ivo: already sheperding a doc for COSE. Will think about this and come back.
Suresh: I can pick somebody for you, doesn't have to be from the WG
Alex (jabber): Perfect, thanks Suresh

[11:13] draft-barthel-lpwan-oam-schc (Dominique)                [5min]
* We have started with simple things like: ICMPv6, Ping
* Scenarios we can consider: user on the Internet wants to debug IP
connectivity issue with traceroute. * But the device will not do probably
traceroute because no user, no keyboard, no display.

Laurent: can have a message that indicates that's the link is LPWAN (useful,
security issue?) Dominique: we want to discuss and see the possibilities
Pascal: we can code somethign on the gateway to be able to answer in place of
the device. There is IPR on this, IPR can be disclosed in this WG Bob: drawing
is unclear, shows IPv6 flowing only in one direction. Dominique: the drawing
explains a scenario. A device sends an IPv6 message, there is a problem in the
netork, we may want an ICMPv6 message back to the device. IPv6 is in both
direction, defineitely. Hacked something out at the Hackation. The way we did
it, is using the compressor logic to look for a Rule that matches the packet
pattern and branck off to special code that sends the ICMPv6 packet back.
Sandra: Question about this scenarios is to be sure that the device is active.
Dominique: good question, this is the base of the discussion, how we want to do
it, how much we want to wait for no device activity until we declare it's not
there, etc Laurent: If you see traffic in the last 5 minutes, you respond that
the device is active. After that, not.

[11:22] draft-gomez-lpwan-rto-considerations (Carles)           [10min]
* Motivation: in some scenarios we have a long RTTs for comparison to the
normal RTT CoAP and TCP * The retransmission is important for fragmentation
answers * In Prague Uplink-RTT * Introduce Downlink-RTT includes the next
transmission (due to sleeping device) and the downlink is completed.

Juan-Carlos: In the LoraWAn which class are you using?
Carles: This is classA, and this numbers are only for the second component

* We have different approaches for the RTO delay, to avoid retries, there is
adifference to retry after 1s than 100s * Dual-RTO algo is the one we have
define to respect the order and compatible with high RTTs * Simulations results

Pascal: My feeling is that we have cross-layer issue. You have these high
mounts for There is chicken-egg between timing out and giving information to
the other end that something has been lost, which is not the case. I think we
need to describe the model in relation to the queue. * Regarding high value
RTO: I don't believe that without cross-layer you can have this information.
The RTO can go infinite if you can not empty the queue fast enough and there is
traffic coming in. Ana: Until now we have taken a device as a device we know.
In LPWAN it is different, it is asymetric, timers are different. There have
been a number of studies that show that those device react slower than what we
expect. This is a first step. I  believe it's interesting, not only the RTT,
but we have other things to study as well. We might consider making one
document with different aspects. Carles: Ana:Assymetric is very important
Pascal: I will welcome a problem statement. We need a greater context. PvdS:
Did you consider Markov chains? Laurent: We eed to adapt server and components

[11:35] Status on IEEE 802.15.4 (Charlie / Bob's slide)         [10min]
Pascal: We will see at the next IETF meeting

[11:38] Rechartering status (Chairs and A-D)                    [15min]

Suresh: charter has been presented, send the charter. Wait for the SCHC
document to be submitted to IESG. 6 weeks in total for the process (internal
review, external review, one more thing). Pascal: Should we include the RTO and
similar topics to the charter, which will change it in regards to how you have
seen it. Problem statement. Suresh: You have 3 weeks, so you can include it.

Pascal: are we ready to work on RTO? please humm if yes. Humms heard. Against?
none heard Ana: how about LWM2M  compression? Pascal: go on the mailing list.
Start with a document. Julien: support for LWM2M. Pascal: please Christian:
needs to be explored, but seems like nothing ot be done specific for LWM2M.
Maybe jut a few options. Pascal: just explain in a doc how this works. Julien:
+1 for LWM2M Pascal: We need the document Daniel Migault: precision on the
charter, have an easy way to use SCHC Pascal: beyond ICMP/OAM, which is already
on the charter, new work would be RTO, LWM2M, Pascal: need for provisioning.
Rule signing.

[11:47] any questions?

[11:47] Adjourn                                            [ QS ]