Minutes interim-2020-lpwan-08: Tue 16:00

Meeting Minutes IPv6 over Low Power Wide-Area Networks (lpwan) WG
Title Minutes interim-2020-lpwan-08: Tue 16:00
State Active
Other versions plain text
Last updated 2020-05-19

Meeting Minutes

       Connection details
    • Date: 7-8am US Pacific DST, 4pm CEST:

    Meeting number (access code): 619 208 505

    Meeting password: tG99jRSJgJ9

    1-650-479-3208 Call-in toll number (US/Canada)
    Tap here to call (mobile phones only, hosts not supported):

    Dial sip:619208505@ietf.webex.com
    You can also dial and enter your meeting number.

    Join using Microsoft Lync or Microsoft Skype for Business
    Dial sip:619208505.ietf@lync.webex.com

    Can't join the meeting?


    * Watson Ladd, Cloudflare
    * Laurent Toutain, IMT Atlantique
    * Ana Minaburo, ACKLIO
    * A Paventhan, ERNET India
    * Pascal Thubert
    * Laurent Toutain
    * Alexander Pelov
    * Dominique Barthel
    * Juan Carlos Zuniga, Sigfox
    * Ivaylo Petrov
    * Olivier Gimenez
    * Eric Vyncke, Cisco
    * Diego Dujovne, UDP
    * Vincent Audebert

    Previous for cc
     - Dominique Barthel
     - Arunprabhu Kandasamy
     - Ricardo Andreasen
     - Diego Dujovne
     - Olivier Gimenez
     - Carles Gomez
     - Juan Carlos Zuniga
     - Ivaylo Petrov
     - Julien Catalano
     - Vincent Audebert
     - Ana MInaburo
     - Laurent Toutain
     - Alexander Pelov
     - Sergio Aguilar


    [16:05] Administrivia                [ 5min]
        o    Note-Well, Scribes, Agenda Bashing
        o    WG Status

    [16:10] SCHC-over-LoRaWAN Update     [30min]
    [16:40] SCHC-over-Sigfox Update      [10min]
    [16:50] AOB                          [ QS ]


    [16:05] Administrivia                [ 5min]
        o    Note-Well, Scribes, Agenda Bashing
        o    WG Status

    * Alexander presents the introduction, IPR BCP etc...
        * Meeting is not recorded, presence is recorded
        * 2 agenda items; no change proposed
        * minutes of last meeting are approved.
        * Ana reports she's working on Security Section for coap draft, to be
        published then. * WG adoption for the OAM draft? Authors would like to
        switch to XML v3 and SVG drawings. * let's decide to drop SVG drawings,
        convert the current text to xml v3 and then edit xml as source code.
        And use XML tables. * will be asked to report at next meeting.

    [16:19] SCHC-over-LoRaWAN Update     [30min]
    * Olivier reports on version -08
    * WGLC ended May 8th
    * Olivier browses through the comments
          * Terminology IETF vs. LoRaWAN
    Eric: Let's use IETF terminology and let's make sure the mapping is present
    in all WG documents. Let's be consistent with the terminology in all drafts
    from this WG. Pascal: Most reviews are going to be from this WG, so it
    makes sense to use IETF terminology. JCZ: There are some updates on the SF
    terminology that might need to be done if the table with the mapping is
    included in some draft. Pascal: object to the use of the term "session" for
    the fragments of a same datagram Laurent: Don't talk about implicit DTags
    as it might be confusing - just talk about RuleIDs. Olivier explains why
    retransmission timer are not used JCZ: I agree. The same issue applies to
    Sigfox. Laurent: in uplink for example, sending... what is the case? JCZ:
    It is application dependent as you don't know how it will behave as it
    depends on the device and the usecase. You can not have a precise timer.
    Pascal: So you are arguing that the timer should be big Dominique: could
    you still have a Retransmission Timer to rell that it is time to try to
    resend, and lower layer will send whenever available? Olivier: If you can
    not send it right away, what do you do? You drop it or you queue it.
    Pascal: You have different strategies, but people that create the devices
    should make sure there are not more applications than could be supported.
    Laurent: You don't want to do an ack-request? Olivier: For uplink you could
    have retransmission timer. Olivier describing Class A ACK-Always downlink
    problem with the timer. If ACK no received at core, can Laurent: You are
    aiming at supporting classes A, B and C, right? Olivier: We are aiming in
    something simple. Most people are using class A anyway Laurent: Maybe don't
    exclude the retramission timer from the draft, but recommend against its
    usage for class A devices. Pascal: ... Olivier: You are not getting stuck,
    because you have the inactivity timer. Dominique: It seems that you cancel
    everything when you lose one fragment?? Laurent: You don't want to fix
    value for the retransmission timer - it will be based on application and
    radio conditions. Can we put that it will be specified by implementers.
    JCZ: It is application dependent. Alex: In some cases you would be able to
    know how much traffic the device generates on average. In other you don't
    know. Can we have an estimate done on the GW. Laurent: Both ends need to
    agree on the value. Olivier: I don't think they need to have the same value
    - for uplink the GW does not need to have specific retransmission timer.
    Olivier: For uplink - set by the application. For downlink Pascal:
    Generally you generate the message, but you add a timebomb or something or
    you let the lower layer Laurent: Retransmission timer is the time during
    which we cannot send retransmission. We can send ACK REQ after this period.
    In a fluid network it will be just after the expiration. In a slotted
    network it is the next transmission opportuninity. Olivier - do we need to
    be explicit about All-1 Pascal: yes, please be explicit.

    [16:40] SCHC-over-Sigfox Update      [10min]
    JCZ presenting the changes for 02
    JCZ: Similar issues like the LoRaWAN draft regarding retransmission timers
    and DL Class-A restrictions. JCZ: All-1 using Seq # from Sigfox. Laurent:
    You do not interleave non-SCHC traffic, right? JCZ: I guess what you are
    asking is if the sequence counter is generic for all applications sending
    data and not necessarily SCHC specific? Dominique: Yes, it seems that you
    are re-using the counter, but if you don't know if there could have been
    other traffic, you can now that you did not lose anything, but if you lost
    something, you can not know if it was SCHC-related or not. JCZ: We will
    look into that and will provide details.

    [16:50] AOB                          [ QS ]