* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Lpwan Status Pages

IPv6 over Low Power Wide-Area Networks (Active WG)
Int Area: Suresh Krishnan, Terry Manderson | 2016-Oct-14 —  
Chairs
 
 


IETF-101 lpwan minutes

Session 2018-03-21 0930-1200: Viscount - Audio stream - lpwan chatroom

Minutes

minutes-101-lpwan-01 minutes



          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]
          
          



Generated from PyHt script /wg/lpwan/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -