Minutes interim-2018-lpwan-10: Wed 17:00

Meeting Minutes IPv6 over Low Power Wide-Area Networks (lpwan) WG
Title Minutes interim-2018-lpwan-10: Wed 17:00
State Active
Other versions plain text
Last updated 2018-09-05

Meeting Minutes

      Connection details

*    Date: September 5th 2018
*    Time: 8-9AM DST, 17:00 CEST:
*    Webex Link:
*    Meeting number: 203 710 782 *    Meeting password: JM3Y2Kqf *    To join
by phone or other means, please go to the Webex Link for details.


*    [17:05] Administrivia                                           [ 5min]
    o    Note-Well, Scribes, Agenda Bashing
    o    Status of drafts
*    [17:10] SCHC Updates since IETF 102 - Dominque                  [10min]
*    [17:20] ACK-on-Error - Juan Carlos, Carles, Edgar               [30min]
*    [17:50] Discussion                                              [10min]
*    [18:00] AOB

Minute takers

*    Ana Minaburo
*    Pascal Thubert
*    Dominique Barthel Orange
*    Carles Gomez
*    Alexander Pelov


* Ana Minaburo
* Laurent Toutain
* Pascal Thubert
* Alexander Pelov
* Carles Gomez
* Dominique Barthel
* Vincent Audebert
* Juan Carlos Zuniga
* Edgard Ramos
* Julien Catalano
* Sivasothy Shanmugalingam
* Flavien Moullec

Past Attendees

Action Items from last time
* Chairs: find reviewers for drafts


*    [17:05] Administrivia                                           [ 5min]
    o    Note-Well, Scribes, Agenda Bashing
    o    Status of drafts

*    [17:10] SCHC Updates since IETF 102 - Dominque                  [10min]
*    [17:20] ACK-on-Error - Juan Carlos, Carles, Edgar               [30min]
*    [17:50] Discussion                                              [10min]
*    [18:00] AOB                                                     [ 0min]


*    [17:05] Administrivia                                           [ 5min]
    o    Note-Well, Scribes, Agenda Bashing
    o    Status of drafts
    * Alex: Reads the Note Well
    * The agenda is accepted nothing to add, the SCHC compression part is
    accepted and will not change * SM in the appendix and the text normative
    for the fragmentation part (to be confirmed on the ML) * SM in normative
    part could be trouble for adoption by other groups, so keep it in appendix
    * Discussion about the ACK-on-Error problematic: there are 3 possibilities
         * first keep it as it is
         * second a big modification and move it to a different document
         * third minor modification but need to understand consequences
    * We need some studies to see the possible modifications and how they
    affect the other uses cases

*    [17:10] SCHC Updates since IETF 102 - Dominque                  [10min]
    * Dominique
    * This is only editorial (no protocol changes) - all changes are on the
    github * * Processing the Charlie Perkins reviews, except section 8 that
    need to be written again * Dominique has sent some questions to finished
    all the process * Edgar input to modify the term L2 Data Unit usage and
    align with the Technology specific terminology * restructure * Appendix D
    has been restructure to be better understandable in order to use only what
    is needed: if F/R is not used, one should not have to specify F/R-related
    parameters! * Section 8 has been restructure to separate the description of
    the messages, the header, the timers, the counter from the algorithmic
    specification of the F/R/ modes. * Need to be done: fill the No-Ack and
    Ack-Always sections for Ack-on-Error will be finished after all the
    discussion and modifications are done. * 7 points with Charlie and doble
    check the SM and appendix * Swift publication to version 17.

*    [17:20] ACK-on-Error - Juan Carlos, Carles, Edgar               [30min]
     * Juan Carlos takes the ball
     * look in the details of ack on error as is
     * consider minimal changes
     * Dominique's changes help a lot already
     * Carles takes the ball
     * Analysis of the issue presented by Juan Carlos. Look at probability, and
     to what extent it can be mitigated * Figure is presented (slide 18).
     scenario is we do not get the SCHC ACK on error, any of the 2 red crosses
     on slide 19. Receiver sends an abort if the next window starts though an
     ack on error was sent * Juan Carlos suggests to send the SCHC ack again,
     and fi the first window first * presenting basic maths to see the chances
     of issue. usus uncorrelated loss to make the problem tractable Note:
     problem will not happen with single window since the ack at the end is
     like ack always. * The proposal improves the situation but does not remove
     it, illustrated in slides 21 22. * Alex: The issue you mention is that you
     have a packet lost * slide 24: smaller window size augment the chances of
     occurences * Alex: you need to lose a first fragment otherwise there is
     not error the trigger ack on error * Edgar: repeating the last message to
     reduce the chances of loss has a cost. * Dominique at some point ack
     always has no worst overhead. We has this proposal to switch mode

*    [17:50] Discussion                                              [10min]
     * Juan Carlos: Look at impact to state machine. We want to keep the same
     number of states. Showing new state machine slide 27. New transitions but
     same number of states. Things where missing in the original SM were fixed
     here as much as possible. * slide 28. Laurent: what is C1 and C2? * Juan
     Carlos: they are transition C, but there are really 2 cases now. * Edgard
     on alt solution slide 31 * Can we go farther than 2 windows? Proposal is
     to ack witha an absolute count packets. xmit vs. transmitted fragments. *
     interoperability could be an issue * Alex: message format with version we
     can know it is an abort * Pascal: I read that as abandon bitmap for ack on
     error * Alex: mean one error message per miss * Laurent: This is an
     extension of what we have done? Now the window is 1 bit, we can extend the
     window to several bits.  We can number windows 0, 1, 2, 3 for smaller
     bitmaps; A bitmap will carry window number/bitmap. This way we limit the
     size of the bitmap. * Juan Carlos: You do not know if there is many errors
     * Edgar for NBioT it could happen for the last packet, switching modes
     would happen in the core network. There is a problem with the switching
     solution. * Edgar we need to consider all the solution and find the good
     one * JCZ all the solutions are based on the ACK-on-error (dont send ACK
     if you dont need to, but when there are errors you still want to recover)
     but perhaps a new mode could be better * Pascal: it is better to have only
     1 window because having more than one may have a lot of troubles * Edgar:
     this is perhaps the conclusion of this study. Considering a use-case for
     SCHC: Ethernet over 5G! * Laurent: it may be a technology depending *
     Alex: very interesting alternatives. At some point in time, we were
     considering having only Ack-Always in this draft and give more time to
     design Ack-on-Error.
    * Alex: Split the ACK-on-Error to a new document without leaving the basic
    one we have produced.
     * Edgar: seems like this is the work that JCZ did, figure the right
     parameters. * JCZ: would not like to see fragmentation in multiple draft.
     * Dominique: with the new structure of the F/R section, it's easy to leave
     subsection 8.3 empty (or remove it) and have a separate draft specify this
     mode, using the same
   * Pascal: we need to finish this meeting, we seems to be in a loop, there is
   a problem there are some propositions (JCZ and Edgar) then we come back to
   the basic one. * Laurent: With a mix with the windows and the bitmap you
   have something new, but Edgar is different

*    [18:00] AOB