Minutes IETF102: lpwan
minutes-102-lpwan-00
| Meeting Minutes | IPv6 over Low Power Wide-Area Networks (lpwan) WG | |
|---|---|---|
| Date and time | 2018-07-19 13:30 | |
| Title | Minutes IETF102: lpwan | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2018-07-19 |
minutes-102-lpwan-00
Meeting : IETF 102 Thursday July 19th, 2018 Time : 9:30-12:00 Montreal Time Morning session I (2H30min) Location : Room Centre Ville, Fairmont The Queen Elizabeth, Montreal Agenda : https://datatracker.ietf.org/meeting/102/materials/agenda-102-lpwan Meeting Slides : https://datatracker.ietf.org/meeting/102/materials.html Etherpad : http://etherpad.tools.ietf.org/p/notes-ietf-102-lpwan?useMonospaceFont=true Meetecho : http://www.meetecho.com/ietf102/lpwan/ Audio stream : http://ietf102streaming.dnsalias.net/ietf/ietf1021.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 Minute takers & Jabber Scribe Francesca on Jabber Ivaylo and Dominique taking notes on Etherpad ------ Agenda ------ * [09:30] Administrivia [15min] o Note-Well, Scribes, Agenda Bashing o Status of drafts (WGLC / forthcoming WGLC) o Presenters: The Chairs * [09:45] draft-ietf-lpwan-ipv6-static-context-hc-16 [45min] o Presenters: Dominique Barthel, Carles Gomez and Ana Minaburo o Goal: info on WGLC conclusion, submit for publication * [10:30] draft-ietf-lpwan-coap-static-context-hc-04 [45min] o Presenter: Laurent Toutain -- Ricardo Andreasen o Goal: WGLC; SCHC/OSCORE presentation * [11:15] draft-petrov-lpwan-ipv6-schc-over-lorawan-02 [10min] o Presenters: Nicolas Sornin (remote) o Goal: present advancement o call for adoption ? * [11:25] draft-zuniga-lpwan-schc-over-sigfox-03 [15min] o Presenters: Juan-Carlos Zuniga o Goal: draft update and discussion about ACK-on-Error mode o call for adoption ? * [11:40] draft-minaburo-lpwan-nbiot-hc-01 [5min] o Presenter: Edgar Ramos o Goal: discuss NB-IoT entities with SCHC * [11:45] draft-toutain-core-time-scale-00 [5min] o Presenter: Laurent Toutain o Goal: Get support from LPWAN to request attention from CORE * [11:50] draft-authors-lpwan-schc-802154 [5min] o Presenters: Charlie Perkins o Goal: ? * [11:55] AOB (Charlie Perkins on IEEE) [ 5min] --- * [09:30] Administrivia [15min] o Note-Well, Scribes, Agenda Bashing * Francesca on Jabber * Ivaylo and Dominique taking notes on Etherpad, others invited to join in o Status of drafts (WGLC / forthcoming WGLC) * baseline tech document DONE. * UDP/IPv6/SCHC on 2nd WGLC * Rechartering will happen as soon as the IP/UDP compression is submitted to IESG - new items - SCHC over CoAP, tech specific documents, ... * Milestones, cleared most of which was listed. today will be diving into IP/UDP * Hackathons short overview - an open source SCHC implementation and a lot of feedback Dominique about the Hackathon: * long term goal to have open source plan for new comers to play with. * non developers are also invited to read the draft and understand. * Two new comers at this hackathon: - micropython on linux for next time * One of the goals was to merge a number or pieces that are already available - not fully finished * [09:42] draft-ietf-lpwan-ipv6-static-context-hc-16 [45min] o Presenters: Dominique Barthel, Carles Gomez and Ana Minaburo o Goal: info on WGLC conclusion, submit for publication Mini-agenda: 20 min for tickets - comments received WGLC2 - 25min Since IETF101, 5 inter-meetings version 10 -16 10 includes , first 10 tickets from wiki. 11 improved Fig3. Answered more comments about the DTag size on all the figures 12 how to compress variable length field. decided to remove y in LSB last 3 versions, continued working on remaining tickets. - boundary, l2words, padding at most once. Same ruleID in the ACK Changed the UDP checksum text. Fixed the SM of ACK always from comments in mailing list and CBit bump. Second last call initiated on June 29th 2018, supposed to be closed today reviewed the comments from Pascal, WGLC to be extended by a week for Charlie and Juan Carlos to review and comment Tickets status Resolution for each Ticket are tracked: https://trac.ietf.org/trac/lpwan/report Dominique explains how the ticket system works and that the information when a ticket is created, how is was closed, etc. Single padding Discussed much during the interim meeting. Idea floated by Laurent. 6 positive responses with no objection. first appeared in draft-14 untill draft-13, - header compression turns IPv6 to bunch of bits. SCHC here is bit oriented. So before sending, padding needs to be done. - fragmentation, adds padding in the last fragment. Hence there are 2 paddings done. - atmost 7 bits in the first and second padding. hence overall 14 bits. - why padding not done at each fragment :? as raised in most hackathons. - because, we use the appropriate number of bits from the rest of the payload instead of padding bits. - reassembly, extra bits removed since the SCHC compressed packet is byte aligned. in 14: - only need padding while sent of layer 2. - don't pad on the compression level if there is fragmentation - how the padding gets removed. - extra bits are ignored or removed at the decompression (based on the rule) Appendix-D (ticket 15) Text is still rough. Restructuring the list is required. Use-case, deployment Mapping of architectural elements L2 integrety RuleID numbering L2 word * If you don't use some parameters, you just state why and you don't specify them * Question: do we structure the list or we leave it as it is? Pascal: If the list is not normative, no need to put a lot of effort to structure it. Dominique: We received feedback that this list is needed from Suresh Pascal: The spec would work exactly the same whether this appendix is there or not, it's just a helper, right, so don't put a WGLC2 comments Comments from Lars, on Traffic Class. - Pascal: don't force the user to use the MO as Ignore. we could include it in, but since there is no transport we can not reflect out. But later if you have the tcp , then including ECN bits would be useful. Traffic class field contains ECN bits. If you use the "ignore" MO will bleach. LPWAN devices usually don't required ECN bits Laurent: The ECN bits are used for upper layers Pascal: If we do not mandate ignore we can leave it. Just make sure the text does not say that the field MUST be ignored. Dominique: OK * Dominique on Soichi feedback: All the libraries that compute CRC are byte aligned, so bit arrays make implementation difficult Arun: I agree Nicolas Sornin: I also agree * Review from Pascal: not fully filled all-0 window is complex and most readers jump to this conclusion anyway * Legal to have parial filling in all windows as of now, which makes the implementation a bit more unclear and takes longer. * Could mandate that the windows are full (generally the prefered way) * Could mandate that after the retransmission there is a new all-0 * Could mandate ... Got 5 supports on the ML, no objection. JCZ: That is fine for the sender, for the receiver we should add extra text Pascal: The text is already there Pascal: Todo for Juan Carlos - check if the text addresses his question (should be the case already) * Pascal feedback: There are cases when the receiver does not know what to expect w=0 or w=1. In the given example, both are possible, but they represent different situations Comment #3 on fragmentation, text is hard to read. Suggestion is to move the state machine up. Ana: we could move the state machine from the Appendix to the text as it is more clear than the text. Pascal: We could do that, but we would need to redo the WGLC. !!! THE ETHERPAD SERVER IS QUITTING INTERMITTENTLY, almost every 5 mins :( yeah... down half the time... Laurent: Silently IGNORE, but if we send the ABORT when there is window+2 sequence, it could be dangerous because the Queue manitained by the network Gateway. (Needs to be discussed detailed) Dominique: has been in the discussion for quite some years. so this has to be defined somewhere properly. Alex: Having the statemachine makes the draft more readable and improves the quality of the draft. Pascal: to Charlie, need more time for the whole document or for the fragmentation ? Are you happy with SCHC-compression? Charlie: 3 weeks needed. fragmentation is the most complicated part of the document. How close of a review you want ? what was being mandated when Layer 2 is already doing fragmentation? (Pascal: ask Edgar for this) Pascal: Suggests to re-open the WGLC only for comments on fragmentation // my notes while I was offline Dominique: We should make this simple. Full windows is one issue, another one is ack-on-error and the dangerous situation is when there is a misalignment between sender and receiver. the text is hard to read and maybe pseudo-code will be easier to read. Laurent said that this is the reason to have the state machine. The Pascal: No reason not to, we just need to redo the WG last call Ana: In the state machine if you don't expect the current window, you drop Carles: I look forward to any form that better expresses our intent. The issue I see is that the reviewers have reviewed the text so far, so we might need more time Pascal: That is why we need the WG last call. People should review the SM and see if it matches well the text, even if we say - check only the fragmentation Alex: We need to produce a good-quality standard and the load on the reviewers should not be that big Pascal: Charlie, do you need to review the whole draft or just the fragmentation. Do you agree - are you happy with the compression Charlie: the fragmentation is the most complex part. The comments for the compression should be easily resolved. A question is - how close a review do you want? I had some concerns when the L2 already supports fragmentation. Pascal: The proposal is to reopen the WGLC only for the fragmentation // end of notes during offline period Charlie: I am sure some people are reading some parts in a slightly different way and they point to examples in the appendix that support their understanding Pascal: If we are pointed to errors, we need to fix them of course Juan Carlos: focus only on the fragmentation is okay. I would rather have the text being the normative side and the state machine being there to help implementers. I didn't go through the SM last night Pascal: The point is that the SM is very concise. Without text, the state machine is hard to understand. Dominique: Yes, we need text and names for states in order to make it understandable Edgar: I support JCZ and - for an implementor it is very nice to have SM as I can just mirror it in my code. For understaing the standard, it is not that intuitive. I would prefer pseudo-code. Another point - if the SM is normative, I will need to mirror this in other documents and that might be very difficult if there are parts that are not used, if there are special cases, etc. Sometimes the why is very important as well - why you send an abort in a given case. Alex: A very nice point. 1) we need to improve the textual description. Maybe what we can do is to give some more time to the reviewers to review the text. Even if the SM is not normative, we need to review it again. Dominique: Suggestion, you have a three-way choice. 1. use text as normative and SM in the appendix 2. have a normative pseudo-code 3. bring the SM as the normative and match with the text. Pascal: I totally agree with you. If we extend the WGLC, we will need to ask people to check the SM. But we will not have to go through a few months to redo the text. Juan Carlos: I would go for option 1. We still have to look at the SM. SM should support the text. that we would like to make more clear anyway Carles: My first choice is also option 1. Pascal: Then there is no need to redo the WGLC and we just can notify the WG Dominique: Option 3 Abdussalam Baryun(From Jabber): Make the SM normative or remove it completely Alex: Dominique, my impression is that in any case we will need to write something like a pseudo-code Dominique: Yes, in the text it is very difficult to explain what is happening or we name the states and we explain things, which will be like pseudo-code Pascal: The text is already there and we need to just structure a bit in order to have what you explained. Dominique: if we want the text to be crystal-clear, it has to paraphrase the State Machine. Charlie: I strongly agree, this is the only way to remove ambiguity. Label states and arcs. Yet, I would not want to have the SM drawing as normative. Edgar: I have a similar concern. I understand that it will make it a lot of text in order to explain it, but that will make it a whole sequence that is easy to understand. It shouldn't be so mixed as it is right now. I think the text could be much better structured, so that it depicts the SM in a much better way. I don't know if the restructuring is option 1 or option 2. egIt is therefore a bit confusing for me what to vote for. Pascal: You need text to Patrick (jabber): if the text is to be normative, it must be correct and non-ambiguous, therefore the state machine is not necessary nor warranted Juan Carlos: Suggestion to have one command by paragraph Alex: It didn't take to a long time to restructure this, right. JCZ: it took me a while but... Alex: Option 1) SM is non-normative and we restructure the text that we have / 11 Option 2) We have the text, but we need to put some pseudo-code around it /1 Option 3) We make the SM normative and some text around it. / 8 Jabber: option 1 option 2 Alex: Option 1 is the most supported, option 2 - only one voice, option 3, some support. Let's take it to the WG Pascal: I saw some authors voting for both 1 and 3, but yeah, there is no clear concensus. Alex: I hear the point that Edgar made that the SM might complicate other technologies. We need to improve the text and we need to check now the SM maps with the text Pascal: Most of the work is exactly the same as the text needs to match it and be understandable. The only thing that I am afraid of is that if a tech needs only a subset, the SM will complicate it. Let's review the SM as if we will make it normative. JCZ: This might make us rethink the technology specific documents * Charlie suggested that some wording could be improved. If we don't fragment, can we still elide the UDP checksum Pascal: don't agree with it. Strength of using UDP (2) and L2 CRC(2) would be 4Bytes. Dominique: Still send the checksum. Pascal: the question is whether we Comment #3 In no Ack mode N = 1 in current draft. JCZ proposes to allow N > 1 in No-Ack mode JCZ: using non MAX_WIND_FCN value in FCN for transmitting in NoACK mode. This way the receiver would have the idea of how much fragments to expect ?? Dominique: This is two separate changes. One is that N>1 be allowed in No-Ack mode. Another one is that FCN does not start at WIND_MAX_FCN. The latter one may have implications in other modes. We need time to discuss it (20 min) * [11:07 (10:30)] draft-ietf-lpwan-coap-static-context-hc-04 [45min] o Presenter: Laurent Toutain -- Ricardo Andreasen o Goal: WGLC; SCHC/OSCORE presentation Change text to explain the difference between CoAP and UDP/IPv6 Add OSCORE implementation - has two parts - one for inner header compression and one for the outer one. * Reminder - the communication is not symetrical, so a better compression can be achieved in some cases using this. * We recommend to use a proxy in some cases to shorten the message ID and the token. Message ID, 16 bytes. MSB allows to compress it for LPWAN. * Token has a variable length. one way is to use the length given by the token length field of the coap. impose a new function for the token length. * URI query repeated, thats why we needed position. For Uri-path if we could combine multiple positions in some field combined in order to achieve better compression. This is would lead to complex implementation. We expect feedback from implementers. Define a matching list for a bunch of paths that shall be combined and use 1bit to compress two path fields instead of 2bit (if they were listed as separate fields). We have a discussion on the ML about coap blocks - whether we need it as we have fragmentation. No answer so far. To do: language revisions to make it more permissive/liberal, add some examples (CoMI ?) Ricardo Andreasen * Explains how OSCORE works * The ideas is to compress the inner-header before it is encrypted by OSCORE and compress the outer-header after the encryption Inner compression, as the same compression as a regular CoAP message The only change is that we need to handle the OSCORE option. We split that into 3 parts, because this way we can mask-out the MSB and just send the part that changes the most. There are 2 parameters that change a lot and usually the rest we can mask-out. We compared the compression with and without the protection and we saw a difference of around 10 bytes comming mostly from the PIV and ... The cost of 10 bytes is fairly consistent. Goran: I like to thank the authors, it is very nice. There is a slight confusion about the term cyphered text. The authentication-... can not be compressed. I point newcommers to this presentation as it is one of the best introductions we have. Francesca: it will be good the text to mandate the need of two rules....... You include the flag bit - maybe a bit obscure - ... Alex: You have 1 more min, so please send your feedback on the mailing list Francesca: You need to re-key if you run out of sequence number * [11:25 (11:15)] draft-petrov-lpwan-ipv6-schc-over-lorawan-02 [10min] o Presenters: Nicolas Sornin (remote) o Goal: present advancement o call for adoption ? Nicolas: 3 classes of device, class A: opens Tx whenever it wants. Provides two opportunities for reception after each transmission. class B: opens synchronous Rx windows, in addition to the mechanism described for Class A. class C: the device is listening all the time when it is not transmitting, it has the lowest latency, but is the most power-consuming one. The diffrent classes impact the way fragmentation is done Have to define parameters for each classes of devices. Proposed first set of parameters for fragmentation on 3 classes of devices. Needs feedback on this from the group regarding the trade off considered in the proposal. Presents the proposed parameters for fragmentations: different for uplinks and downlinks as uplink capacity is much more than downlink one. - Uplink: ruleID is 3 bits, DTag is 1 bit, 1 bit window, FCN 3 bits Every single downlink is ack'ed from the device, hence fcn size is 1bit. We have implemented some examples with 3 rules, so feedback could be appreciated. Alex (Chair heat off): Have a prefix for pre-defined rules and have device specific rules Nicolas: Is it possible to have a variable length rule ID Alex: Yes, yes, it is possible.Variable length rule ID is allowed as per the current draft. Nicolas: What is the spirit of the IETF about default rules Alex: We should discuss this on the ML, but my feeling is that we should have some common rules to facilitate the implementations. Laurent: I also agree that having pre-defined rules to bootstrap could be useful. If the rule ID is 0, specify on how much bits it is represented. Nicolas: more things as to be done : * discuss and describe security model * describe specificities of 3 devices classes (A/B/C). * provide detailed frame exchange examples Feedback on SCHC, find a way for device to send rules to SCHC gtw (rule provisionning). we should have a way to provision in-band the context, as otherwise it will be a nightmare Pascal: We will look into that when we finish the SCHC draft and we are rechartered, but for sure that will be a very important part. Pascal: as soon as SCH draft is out, we recharter and intend to introduce work on provisioning. Nicolas : other suggestion is to have introductory rule and conclusion rule. Allows to interface legacy devices. Pascal: will discuss it on the mailing list. [Note enterd here by Dominique after the meeting: this suggestion was made earlier, captured as Ticket #14 and closed. We need to dicuss about it again]. Nicolas: I am not familiar with the process, but I think it will be good if this document could become an official WG document Pascal: Yes, as there is no opposition in the hall, we will call for adoption on the ML and as soon as the WG is chartered for it, we will do it (10 min) * [11:35 (11:25)] draft-zuniga-lpwan-schc-over-sigfox-03 [15min] o Presenters: Juan-Carlos Zuniga o Goal: draft update and discussion about ACK-on-Error mode o call for adoption ? Juan Carlos: SCHC OVER Sigox Added values on timers, values for fragmentation. needed some clarification on noack , presenting in next slides. Proposal: relax the specification, higher than 1 fcn size is allowed. If we didn't start at the MAX_WIND_FCN value, the receiver knows the number of fragments that it needs to expect. Proposal on ACK-error: Allow ACK-Error to track last 2 windows. The reason is that if we lose a single all-0 or it's ack means an abort and total loss of session. Receiver can request lost fragment from the previous window. there is some risk involved in managing the window bit. Pascal: ... the discussion earlier about the SM, with this proposal will make it much more complicated. Alex: I think you need to have an error in order to have a problem Ana: You are choosing Ack-on-error as you want to save your downlink and you use ack-always if you want to be able to handle this type of situations without abort. Alex: Let's discuss this on the ML Laurent: I understood that you have test results. Could you share the diference in the performance. * [11:48 (11:40)] draft-minaburo-lpwan-nbiot-hc-01 [5min] o Presenter: Edgar Ramos o Goal: discuss NB-IoT entities with SCHC Disucss what are the possibilities to continue further with the draft. 2 ways of trasnmitting data: using contrl plane: stack included the control plane protocol using user plane. basically IP, using PDCP. conclusion for SCHC: using 3GPP standard interfaces, Non IP traffic. replace RoHC with alternative that could be SCHC. needs to take care of provisioning the parameters and functionality remains same. interest exist with 3GPP once SCHC becomes standard. There are 2 places where SCHC could be. In the NAS level or on Connected mode. In one of the case(Connected mode) the security has been established and in the other(NAS) it is not. That should be considered especially iff it is possible to reuse context... SCHC as application layer packets doesn't need 3GPP standardisation. It would be considered as NonIP traffic. implications is that intermediate hops cannot understand compressed IP headers. Pascal: if we are on the non-IP path, do we have guarantee that the packets are in order. Edgar: From the core network to the device they are in order. In the middle before I don't know if something could happen Pascal: In the core maybe there are multiple paths accross tunnels and if UDP is used, there might be reordering, sequencing needed. Edgar: This is something to check, but it depends also on the deployment Improve the document, missed the deadline for submission, have the newer version in the github. Alex: Thank you and I see the advancement (X) * [SKIP - 11:45] draft-toutain-core-time-scale-00 [5min] o Presenter: Laurent Toutain o Goal: Get support from LPWAN to request attention from CORE * [11:56 (11:50)] draft-authors-lpwan-schc-802154 [5min] o Presenters: Charlie Perkins o Goal: ? - submitted the draft earlier this week. - 802.15.4w dealing with lowpower wide area. not official publication. - SCHC parameters specified. ruleID size = 3 bits, - padding to byte boundaries. - either CRC32 or CRC16. - already does fragmentation at 802.15.4 so not needed. But it is yet not analyzed whether the SCHC fragmenetation is better than the existing one, so this is something to be done. - Other 802.15.4w status. 4 MAC layer proposals. 2 PHY proposals. would love to hear any concerns to be forwarded to 802154 group. * [11:55] AOB (Charlie Perkins on IEEE) [ 5min]