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, Chairs         :   Pascal Thubert                    Alexander Pelov (remote)                    Dominique Barthel (stand-in, thank you!) Responsible AD :   Suresh Krishnan Live minutes   : Live feeds     :   Other URLs     :                :                :                :                                     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,, 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 ]