Meeting : IETF 101 - 2h30 Time : March 21, 2018, 9:30-12:00 (150min) Location : Hilton London Metropole, London Chairs : Pascal Thubert Alexander Pelov Responsible AD : Suresh Krishnan URLs : http://tools.ietf.org/wg/lpwan/ https://datatracker.ietf.org/wg/lpwan/ https://www.ietf.org/mailman/listinfo/lpwan Agenda ------ * [09:30] Administrivia [15min] o Note-Well, Scribes, Agenda Bashing Pascal Thubert (PT) presents the new Note-Well Minute takers: Ivaylo Petrov, Julien Catalano, Carles Gomez, Dominique Barthel, Ana Minaburo, Georgios, Laurent,Edgar Ramos Jabber: Rahul Dominique requests a presentation for the Hackathon. o Status of drafts (WGLC / forthcoming WGLC) o Presenters: The Chairs Alex: presents the charter and milestones of the WG * [09:38] Hackathon o Presenters: Dominique Barthel Alex encourages us to participate in the following hackathons Two days of focused time. Everybody welcome and accomodated. Even if you don't have your own code, come play with the provided device and run open-source code. This fosters feedback, discussions, testing. Two technologies used (LoRaWAN, Sigfox), different platforms, 8 participants (1 remote) * [09:43] draft-ietf-lpwan-overview [ 5min] o LPWAN Overview - Doc status and updates o Presenters: The Chairs Progress with the IESG is very good. We got great comments. Asked Suresh if anything else to say (Suresh says "nothing else"). * [09:45] draft-ietf-lpwan-ipv6-static-context-hc [60min] o Presenters: Dominique Barthel (Shepherd) and Ana Minaburo Ana presents updates to -10 since last IETF. Work on fragmentation. In version 10. editorial change, abstract reduced, terminology added Three new sections: SCHC overview, Rule Id, Padding Clarify naming of fragmentation modes. 3 names remain: No Ack, Ack on error, Ack Always. We don't use the name "Window modes" any more. Corrected errors in the state machine. Closed tickets: * questions on Rule I. Answered and closed the ticket, but more explanation work has to be done in the wg, since questions comes up again. * Zip bomb, added to security section * Clarification on DTAG behavior * Hypothesis : we nay say that we assume that there is no "out of sequence" delivery by the undelying technology. * are default value of fields defined (e.g. IPv6 Hop Count)? this draft defines the SCHC mechanism, no the Rule details. The default value for the fields that a vendor will want to compress will be in the rule, which he defines. * is it acceptable to fill partially a window? the All-1 window it is the last one of a packet so usually not completely filled (for lack of data). All-0 windows MUST be filled if Ack-always node is used, no MUST in the other modes. * DNS lookup: out of scope since the goal is to compress not to to define the rule. * list of SCHC paramaters that a technology document must specify? this list will be provided in the upcoming revisions. Dominique: this was a recap on the closed tickets. They were discussed during the interims + mailing list. The discussion is now on the open tickets. Dominique presents open tickets, grouped in general themes. #5 #13 : Overview. Comments ask precision on how Compression and fragmentation are arranged, how they work together. Ana: The SCHC overview (tickets) were addressed by adding text on how the fragmentation and compression are working together. The first step is compression. If no rule is found to match, a specific Rule Id is added in front of the packet to say so. Dominique: One of the source for confusion was that there was no name for the "thing" after the compression. Now called "the SCHC packet", whether a rule was found for compression or not. Ana: SCHC packet is a compressed packet or a packet for which compression has not been possible (but it will also have a Rule ID) Dominique: There will be capitalization to indicate a SCHC "P"acket and SCHC "F"ragment A next figure is proposed for -11 to explain the link between compression and fragmentation Ana explains a figure. After SCHC Compression, if SCHC packet fits L2 there will be no Fragmentation and, thus, it will b e transmitted. Otherwise, there will be a SCHC Fragmentation. Thus, the SCHC packet will be splitted to SCHC Fragment(s) and then transmitted. JC Zúñiga; Does this assume any rule ID space? Dominique: We will come back to this later. Alex requests the room to raise their hand or come to the mic if they do not agree with the proposed solutions for the following open tickets. Rahul Jadhav (from Jabber - Shoichi): how can you know if a packet has not been compressed or is a fragment? Ana: based on the Rule ID. We have a slide later Dominique: clarification in terminology: - compressed header : Something that was not understood was that we are only compressing the headers, not the payload itself. - compression residue: what is not defined in the rule and has to be sent - fragmentation header JCZ: simplify the figure: just one fragment in the figure Ack was defined as a special case of a fragment, but it is confusing; new term: SCHC Ack No name for line in rule table => Field Description. Georgios: Asks about the figure on slide 8 in connection to Acks. Ana: ACK are only for SCHC Fragments. Dominique: Should we add SCHC ACK in SCHC Overview figure? "Yes" in the room. Edgar: we have had that discussion in the interim. Depending on tech, we would not have frag at all It might be good to decide whether there is fragmentation in the technology specific document. Dominique: yes, we had your case in mind, so we will add the diamond shape to indicate the condition ("if" frag is needed or not) Suresh: Edgar: in NB-IoT, segmentation can be done on the lower layer, it makes sense not to have fragmentation in certain transmission modes from the overhead perspective For NB-Iot you can have link adaptation. You don't have any idea about the size until a couple of ms before the transmission Dominique: What will be the correct term here. We are refurring to L2, but maybe Alex: This figure is only for global view, maybe it should not be too complicated in order to make it easier to people to grasp. Dominique: We are discussing between the previous figure, the currently proposed one, or a diamond like shape. Edgar: What does it mean "if needed". Mayabe it should be explained some sort of default and point to the dedicated tecnology documents for a more specific treatment . Suresh: I would like have some information that the decision is made in the "if" part, and maybe have a reference to a place where it is explained in more details. Juan-Carlos: Supports previous points. Add Forward reference to L2 technology, and add this "decision to fragment or not" to the list (appendix) of issues to be resolved in the L2 tech-specific documents. Dominique: MSB and LSB, what does it mean, etc. MSB and LSB are not necessary to be used together, but it makes a lot of sense. The draft currently does not explain what happens in the corner cases - when x + y is more than the bytes available. Ana: It is possible "y" to be omitted if x and the length is known (it is fixed), than y could be the remaining bits. Dominique: What happens if "x" and "y" do not equal the field size. You just don't send them and those bits will be replaced on the other hand Dominique: does anybody have strong objections to this behavior? Pascal (from the floor): do you have a particular case why you use it? In some cases it might be good to be filled with 0s, but do you think there might be cases where this is not the case. Laurent: we are in a very strange case, I see no cases where you can apply this. If remaining bits are known, extend X size. Dominique: Do we simplify the draft by just saying y = len - x? Alexander Pelov (floor): it's good to be able to specify LSB. No strong opinion on this. It's good to have it as it is. Minimum changes to the draft. Ivaylo: wants to see written in the draft "fill with 0" Dominique: the way it's written is clear. We just always take it from the target value. Laurent: currently we don't put the argument, we just put LSB. It's better to remove the argument. I.e. don't put "y" anymore. Just put LSB. In the CDA we just have LSB, and no argument. Dominique notes that this is what is already discribed at the bottom of the slide, under "if y is absent". Just make it the only one behaviour #18: Variable length fields Variable length fields were created in SCHC to accomodate CoAP URIs. CoAP has variable length field (URIs). Except for that, the protocols considered have fixed-length fields, known from the specification the protocol. 1st typical use: MO: Ignored + CDA: Value-sent. This situation is when we get some random URI in the CoAP message, that we have no way of anticipating. Since the URI string is of variable length, we have to send the field length along with the field value. Length is expressed in bytes (not bits), because URIs are byte-aligned. All other field lengths in SCHC are expressed in bits. This is disturbing when you read the spec. But saves 3 bits on the wire. How to encode the length? too many bits, you are wasting bits. Too few, you are constraining the field size. Idea: Use variable length (!). Like CBOR, but not CBOR. So the draft talks about the length and also about the length of the length. Trying to make the draft easier to read, more explicit. How to name the "length of the length" field in the draft? Laurent: Right now in the rule if the field is of variable length, you put "VAR" in the table. The units of the length is in bytes. If we later discover that we have a need for variable-length fields that are not byte-aligned, we can add a new keyword and have length in bits. Suresh: Why is this encoding different from that of CBOR ? Why does it have to be? Laurent: We want to encode as many small values as possible. Then we extend to the next size when we reach the limit. 2nd typical case: MO: Match-mapping + CDA: Mapping-sent. This is when you expect a few specific URIs. The index in the list is sent instead of the string. Pascal: you may want to be case insensitive - DNS name for example. Laurent: Currently we are case sensitive Pascal: Maybe it will be good to have a way to express this. Laurent: It is not only the mapping operator, also equals needs to be modified for this. Suresh: I think text in the draft is wrong [on variable length encoding of length], doesn't catch the condition properly (255 vs 254). Dominique: correct, there is a mistake in the draft. Captured already. Rahul (jabber -> Shoichi): The size of the index is defined in the rule table. Dominique: Yes, indirectly. It can be computed based on the number of elements in the list. The list is the TV of the Field Description, known statically. Laurent: the index MUST be of the minimal length to enumerate all elements in the list. Suresh: OK to not open a new WGLC, just send a mail to the mailing list to have a one week call for the people to be able to review the specific parts of the document that were changed. Suresh: need to add pointers from the Trac -> text (or vice versa) to be able to say: this Ticket was closed with that text edit, or THIS text edit fixes THAT ticket #5 #14: Rule ID Draft does not define the size of the Rule ID, nor even any numbering system. Rule ID size doesn't need to be fixed. Variable length is possible for the Rule ID. Edgar: I think it's important. Otherwise, if you have a packet that is not compressed, then you are adding overhead. Ana: Rule ID could be one bit. Edgar: If it is one bit, you might need to include a byte as the data could be byte aligned. I'm supporting what you're saying [note: the variable length encoding of the RuleId].. Dominique: Figures 9 to 23 show a R-sized fragment header. R doesn't have to be a constant. I was myself confused by that, I assumed R meant constant. We could remove the R in the drawing to avoid confusion. Ana: DTag has variable length, so is FCN. Replace "R" with "Fragment header"? JCZ: We are trying to understand this that is why we are silent. Will it vary for the same tech over time? Ana: All the fragments from the same packet will be of the same size. Laurent: It will vary from Fragment ID to Fragment ID. Laurent: R might vary from one rule [note: meaning, Fragment ID] to another. Dominique: The size may vary and we want to clarify this. Ana: It could be both. The technology will give you guidelines, but it's up to the implementors. Dominique: In Lora for example you can use the fPort byte for the RuleID or FragmentID as long as you don't use reserved values. This is already there in the L2 PDU, so it's "free". Julien: How do you get the ruleID size if it's variable in size? Dominique: You might need to look at the bits in the Rule ID value to get its size. This is standard for variable length encoding. Ivaylo: You will know the context for the device. From there you might need to compare to all the rule IDs and it is up to the context creators to make sure it will not match multiple rules. Domique: recommendation to the authors to explicit WHY we have Rule IDs, what they are used for (what are the properties to be followed by the Rule IDs for the intended properties to be fulfilled) Suresh: what are you trying to fix? Seems quite good as it is. It seems not as straightforward, but can be cleared easily / if clarified that is techno specific. Dominique: not trying to fix anything in the behavior here, only make specification clearer to those who will try to understand it later. Dominique: It seems to me the R in the figure is conveying a wrong idea that the size is fixed for all the packets on a network. Carles: one thing to keep in mind is that Rule IDs used for compression and for fragmentation share the same Rule ID space Dominique: You need to be able to tell things apart. That is why we need to have the same space for fragmentation and compression IDs. * Padding: Ana: The padding could be used. Dominique: We have a specific technology (namely Sigfox) which is able to transport any number of bits (not byte aligned). We do not want to constrain L2 technology. JCZ: Clarifying, in Sigfox you can sent either 1 bit or bytes. In downlink you need to send 8 bytes always. Pascal: You will have to shift the payload. Dominique: Yes. We assume computation is free, compared to transmission. Suresh: I find the issue tracking a little bit difficult. Given that everything is on the ML, it is hard to follow. Ana: I created them in the issue tracker, but as there was no automatic email to the mailing list, I forwarded it myself. Suresh: I don't see the links anywhere. Dominique: will be explicitely provided on the ML. * #11, #21 Ack formats The format of the acks that are not last is different from that of the last one. In the last one, there is a C bit that signifies if the MIC matched. So the last ack has one more bit than the previous ones. Is it a problem or not. It may be on technologies with small L2 payloads. Ana: Could make the last window shorter than the previous ones. Dominique: * Two options: - not change the behavior, add explicit warning in the text that, if L2 payload size is the limit to your window size, developers should remember that the window size need to be one fragment shorter than they would think looking at the All-0 ACK format, in order to accomodate for the extra bit of the All-1 ACK. - or we could change the behavior and specify that the last window always has one fragment less than the other windows This way, the bitmap in the All-1 ACK has one less bit, and there is always room, by design, for the extra bit. Carles: I think it is fine as it is (option 1). Maybe it's connected that I am the author, but I think we can just rephrase it. Laurent: I think we should document it, but it seems fine. It is really rare the case anyway (that the window size would be constrained by the L2 PDU size). Alex: Could we provide this in tech specific document? Pascal: We can not leave to tech specific technology documents as there are not any option provided. [post-meeeting note by Dominique: Pascal, I now understand what you meant: we could describe the two behaviors and leave it to the tech document to decide which one to use. Currently, we specify only one option or the other and leave no choice to the technology document. I will ask for feedback from the group.] Laurent: Do we need to have a new Last Call after -11? Suresh: I don't need another Last Call, as long as there is a way to see where and how each ticket was fixed. There is no correlation between tracker and the version where it is fixed. Maybe we can add this to the tracker, or in a revision list in the draft. * [11:12] draft-petrov-lpwan-ipv6-schc-over-lorawan [10min] o Presenters: Juilen Catalano A good representative group of Lorawan technology Architecture document and describe where SCHC C/D F/R will be placed. IPv6/UDP with 0 bit sent on the wire CoAP with POST and GET Fragmentation parameters for uplink, downlink class A (sleeping device) and downlink class B (beacon) and C (always listeming devices) End goal for loRa Alliance: HTTP (with CoAP proxy) Dominique: What do you mean by end-to-end HTTP POST? Julien: Device POSTs a value, that get posted in the cloud. The final idea is to have conversion between HTTP and CoAP with a proxy. Dominique: So end-to-end POST, but not end-to-end HTTP. Julien: Yes. JCZ: you are not planning to have HTTP over SCHC. Julien: No, CoAP to the compressor and then HTTP proxy to the application. Pascal: Suresh if the packet is fragmented, we might have very big checksum that is strong. If the packet is not fragmented, we are generally eliding UDP checksum. I want to make you aware of this. Suresh: Pascal: In 6loPAN we claim that we have strong enough checksum in the underlying technology, so it is fine. Suresh: If there is any prior work, we can just discuss it here. Otherwise we must have broader discussion. Alex: in ticket #15, also add that technology developper must asses that L2 has strong enough integrity checking to match SCHC's assumption. Pascal: Let's take this offline, but we will need to do the work. * [11:23] draft-zuniga-lpwan-schc-over-sigfox [ 5min] o Presenters: Juan-Carlos Zuniga A lot of work "behind the scenes" - testing and optimizing internally. Plan to provide recommendations in the next revision. * [11:26] draft-minaburo-lpwan-nbiot-hc [ 5min] o Presenter: Edgar Ramos In NB-IoT there is different way to transmit data , depending on device state (connected, un-connected, power-save modes) Bearer handling: device can go from one mode to another (depending of the buffer size) Mobility is possible (device is sleeping and wake up in another network) add LTE-M and 5G NR-MTC (the definition is just begining) Transmission mode: DoNAS: full use of SCHC features Connected mode: reliability and segmentation provided. Doesn't need the corresponding SCHC features. Padding is handled by low layers study the transition between the modes JCZ: for the connected mode, is the idea to have IP in IP? Edgar: not sure at this point * [11:35] SCHC for ICMPv6 [ 5min] o draft-lagos-lpwan-icmpv6-static-context-hc o draft-barthel-icmpv6-schc o Presenters: Diego Dujovne and Dominique Barthel Diego: define some rule for ICMPv6 messages for LoRa Dominique: no progress on the draft, but prototyped ping proxy on server side. Discussion with Diego on merging the two drafts. This draft on use-cases and architecture (proxying, etc), not so much on how the compression is performed. Charlie: in IEEE there is now a lpw group that has been approved. Compression for 802.15.4 Alex: would be good to have a presentation on that Suresh: Some time ago we were consnidering creating new ICMP tags... Suresh: define the ICMP types you will support/compress. Julien: I fully support such initiative. Peter vdS: I would like to see comparisons. Pascal: This information will not fly all the time. Alex: We will need to configure parts of the context, maybe not the whole context. Peter vdS: So you are looking to ease of specification. Alex: I would say so and the ease of defining minor patches, but also that does not put burden on large scale deployments. Ari: Please use something already existing. Alex: Sure, thank you. * [11:43] Data models [10min] o Presenters: Alexander Pelov We will need to have context modifications and discovery in some cases. We will end up with more things for sure. That is why we need some schema in order to express the context. A way we could take is YANG. There is CoMI that is designed for constrained networks and might be a good way to go. * [11:49] Rechartering [30min] o Discussion lead by the Chairs Suresh: Sounds good. I would also like to see updates on the milestone dates. It still has May 2017 items! Need realistic estimates. Alex: We will do this and we got the message that we need to finish SCHC over IP/UDP before we do rechartering. Alex: regarding SCHC for CoAP, * [11:55] AOB [ 5min]